Developer overview
What's so special about devs and URLs
Backend and full-stack devs have always needed URLs to publish their work privately and publicly before deployment to production. But typically URLs come last: once the infrastructure is ready, it is up to a DNS setting to assign a public name, so a URL can be published to match some server over the Internet. The server will be listening on its IP and port, more usually a load balancer will front all public connection with a proxy handling SSL certificates and more than often, a dedicated team will take the code for production once a production branch is committed in a git repo and communicated to their team.
But before the app is ready for production, full-stack developers can quickly get lost in the complexity inherent to deployment. Some vendors such as Vercel have greatly simplified the process with ephemeral URLs matching each release, and long before static URLs will be assigned when the production stage is reached.
Yet for a full stack developer, not simply relying on SSR technology, but an accompanying back-end API server, it has proven not to be enough as URL should be also provided to the back-end; and this only further complicates the setting.
All backend devs, one day, have to deal with publishing ports for HTTP listener and any real pro has to suffer with TLS allocation and automatic renewal while learning the intricacies of a reverse proxy configuration language (mostly needed, so the dev stage app does not directly expose private data, but also to route various path, appearing after the URL, to various apps).
Reducing the admin clutter
All full-stack developers have usually to deal with at least three distinct control panels to deploy their stack during dev and staging: DNS panel, Proxy configuration, and Network Routing.
Setip.io merges at least three otherwise loosely related control panels into one simple UI:
TLS automation and TLS front end: so no need to handle TLS in code, and you get HTTPS even during dev,
DNS automation: allowing to simply name a needed URL for it to exist and be handled everywhere;
Zero Trust automation, allowing to run code remotely from the public endpoint on the cloud as opposed to only at the cloud vendor premises, and that could be on a dev laptop or a docker container in-house.
With setip.io developers can now define a public URL while assigning it a route (/api, /auth…) and any destination: including a dev machine or a Kubernetes deployment. This is now done from one control panel configuration instead of trying to coordinate and install three different services, including DNS, Proxy, and some Zero Trust solutions.
URLs can point to internal IPs and ports running pre-configured open-source packages. In the example below an EC2 server is running an instance of pocketbase and is assigned an IP ending with .11 so sending an URL to port 8090 on this server is as simple as addressing it as: http://peer11:8090.
Please note that the origin is defined as http and not https, even though the url pb.setip.io is listening over https. All traffic between your URL public face and the port published by the server app is encrypted through WireGuard, a highly secure and fast Zero Trust protocol now built-in Linux kernel.
And if you want to bring in your proxy you can always create your account in "Transparent" mode, but beware as all traffic to and from your public IP will be carried to the host running your WireGuard connection so make sure it is secured and isolated from the rest of your network or get clearance from your network admin before you do.
It is possible to create multiple similar URLs as long as you choose a different path. This can allow you to send any api call to the same website as your main website, for example, but make sure that any URL that starts with /api is directed to another backend or on the same backend but to a different port.
Relying only on tunneling solutions will not coordinate but only route some or all packets to their destination and miss coordination with the matching access and security processes and configuration: This makes it more difficult for devs to get to quickly publish initial results to the world.
Some utility features are also added: a simple Tail, so it is easier to trace requests through the DNS, the Proxy, and code from one simple interface. Tail is also available from an API so one can build one own log search app.