Why a bare IP is a problem
An address like 203.0.113.10 works, but it creates three concrete obstacles the moment you want to go further.
First, TLS is impossible on a bare IP. Let's Encrypt and other certificate authorities refuse to issue a certificate for a bare public IP. Without a certificate, your browser shows "Not secure" and your reverse proxy has nothing to terminate on the HTTPS side.
Second, the IP is unstable by design. If you reinstall the VPS, migrate to a higher plan or change datacenter, the IP changes. All your configurations — internal DNS, app config files, SSH commands in your password manager — instantly become wrong.
Third, a reverse proxy needs a hostname. Nginx and Caddy rely on the Host: header to route requests to the right backend. On a bare IP, this field is the IP itself, which complicates hosting multiple services on the same server.
Situations where a temporary address (without your own domain) is the right answer
- You're testing a self-hosted tool before deciding whether to keep the VPS.
- You're waiting for a domain transfer to complete (5 to 7 days with some registrars).
- You're setting up an internal staging environment that no one outside will ever reach.
- You're prototyping an API or webhook and need an externally reachable HTTPS URL.
- Your client hasn't given you their domain yet, but the sprint starts tomorrow.
- You're exploring a subdomain for a side project before deciding whether it deserves its own domain.
- You're configuring your mail server's reverse DNS (PTR) and need a consistent FQDN right now.
- You're accessing your VPS from a network that blocks direct IP connections (some firewalls filter destinations without SNI).
Prerequisites common to all three options
Before choosing, make sure you have:
An active VPS accessible over SSH. The command ssh root@<vps-ip> must respond. If your VPS was just delivered, wait a few minutes for the image to finish deploying.
Access to the management console (ServOrbit client area for option 1, browser access for options 2 and 3).
Basic DNS knowledge: knowing that an A record points a name to an IP, and that a high TTL slows propagation. For options 2 and 3, nothing else is required server-side — the services handle the rest.
Option 1 — the ServOrbit subdomain: the immediate address
Every ServOrbit VPS receives a hostname of the form vps-xxxxxxx.servorbit-dns.com at delivery. It's assigned automatically, points to your server's IP, and stays valid even if that IP changes after a reinstall. This is the zero-friction solution: no third-party account, no client to install, no cron to configure.
Activate and use the ServOrbit subdomain
Find your address in the client area
Log in, open VPS → Manage. The access block shows your vps-xxxxxxx.servorbit-dns.com address in place of the IP. A button copies the full SSH command — ssh [email protected].
Replace the IP with this name everywhere
In your application configuration, your SSH client, your deployment scripts: substitute the IP with the subdomain. The address stays valid after a reinstall that would change the IP.
Publish an application with HTTPS without writing a single line of config
In VPS → Manage → Applications, pick your template and select the free subdomain instead of entering a domain. The installer configures the reverse proxy (Caddy or Nginx Proxy Manager depending on the template), requests a Let's Encrypt certificate and gives you a URL like my-app.vps-xxxxxxx.servorbit-dns.com, ready to use over HTTPS within minutes.
Set your reverse DNS (PTR) in one click
If you're hosting a mail server, go to Network & security → Reverse DNS, enter vps-xxxxxxx.servorbit-dns.com and confirm. Since this name already resolves to your VPS's IP, the PTR is immediately "confirmed" — the necessary condition for receiving mail servers not to classify your emails as spam.
Attach your domain when you're ready
When you buy or transfer a domain, attach it to the VPS from the client area. The servorbit-dns.com subdomain remains active in parallel during the transition — no existing link breaks, nothing to reconfigure.
Option 2 — free dynamic DNS (Afraid.org, deSEC, nsupdate.info)
If you want a more personalised name, or if you manage multiple VPS across different providers, free dynamic DNS services are a serious alternative. Afraid.org lets you pick a subdomain under around fifty public domains (mooo.com, myftp.org…). deSEC lets you bring your own domain and manages DNS for you, for free, with an API for updates. nsupdate.info follows the same principle with a simpler interface.
The mechanism is the same for all three: a DDNS client runs on your VPS, detects IP changes and updates the A record via the service's API. Result: your subdomain follows the IP, even if it changes.
Set up dynamic DNS (example with deSEC)
Create an account and a subdomain on desec.io
On desec.io, create an account, then add a subdomain (example: myvps.dedyn.io). deSEC generates an API access token — copy it.
Install ddclient on your VPS
On Debian/Ubuntu: apt install ddclient. During installation, select any compatible protocol or answer freely — you'll replace the config anyway.
Configure /etc/ddclient.conf
Edit the file with your token and subdomain. deSEC provides direct documentation on its site for the exact configuration block for your version of ddclient.
Start the service and verify propagation
Run systemctl enable --now ddclient, then wait 1 to 2 minutes. Check resolution with dig myvps.dedyn.io A from an external machine. If the returned IP matches your VPS, you're set.
Get a TLS certificate with Caddy or Certbot
With Caddy (apt install caddy), a minimal Caddyfile is enough: myvps.dedyn.io { reverse_proxy localhost:3000 }. Caddy negotiates the Let's Encrypt certificate on its own. With Certbot, run certbot certonly --standalone -d myvps.dedyn.io.
Option 3 — development tunnel (Cloudflare Tunnel or ngrok)
Reverse tunnels are the fastest way to expose a service on a VPS behind NAT, without opening ports or configuring DNS. Cloudflare Tunnel (cloudflared) creates an encrypted tunnel between your VPS and Cloudflare's edge, which exposes your service on a trycloudflare.com subdomain (temporary mode, no account required) or on your own domain if you have one in Cloudflare. ngrok works on the same principle and assigns a random URL renewed at each start (free account) or a fixed URL (paid account).
These tools are perfect for demonstrating a prototype, testing a Stripe or GitHub webhook, or supporting a client remotely without modifying the firewall. They don't replace permanent infrastructure: the extra latency and bandwidth limits of free plans keep them in the development and staging lane.
Expose a service in 3 minutes with Cloudflare Tunnel (temporary mode)
Install cloudflared on your VPS
Download the binary from github.com/cloudflare/cloudflared/releases and make it executable: chmod +x cloudflared && mv cloudflared /usr/local/bin/.
Start a temporary tunnel to your service
If your application listens on port 8080: cloudflared tunnel --url http://localhost:8080. Cloudflare displays a URL in *.trycloudflare.com — share it. It expires when you close the process.
For a permanent tunnel, create an account and a named tunnel
Log in with cloudflared tunnel login, create a tunnel (cloudflared tunnel create my-tunnel), configure the YAML file and register the service (cloudflared service install). The tunnel restarts with the VPS.
When to switch to a real domain
These three options are starter or development solutions. Switch to a domain of your own as soon as one of these conditions applies.
Production TLS. Let's Encrypt issues certificates for registered domain names; on a third-party subdomain, you depend on their infrastructure and retention policy.
SEO. A blog post, a landing page or an online shop builds no domain authority on a third-party subdomain. Your content will be indexed, but the trust signal goes to the parent domain, not you.
Client trust. Sharing a URL in myapp.vps-xxxxxxx.servorbit-dns.com or myapplication.trycloudflare.com with an end client creates unnecessary friction. A domain of your own is a professionalism signal you can't buy back after the fact.
On ServOrbit, registering or transferring a domain and attaching it to the VPS takes a few clicks from the client area — and the free subdomain stays available in parallel throughout the transition.
Troubleshooting — the 4 most common errors
DNS not yet propagated. Propagation of an A record can take from a few seconds (low TTL) to 48 hours (TTL inherited from an old registrar). Check with dig +short your-subdomain-name A from an external machine — your OS often caches a stale response. The ServOrbit subdomain propagates immediately at delivery: if dig doesn't respond, check for a typo in the address.
TLS rejected on bare IP. If Certbot or Caddy throws an error like "Domain not found" or "Invalid domain", you tried to issue a certificate for an IP address. Replace the IP with your hostname in the reverse proxy configuration and try again.
ServOrbit subdomain not assigned. If vps-xxxxxxx.servorbit-dns.com doesn't resolve, open the client area and verify the VPS is in Active state (not still being installed). On a freshly delivered VPS, wait 2 to 3 minutes for the DNS assignment to propagate.
Cloudflare Tunnel closing. In temporary mode (--url), the tunnel lives as long as the process. If your SSH connection drops, the tunnel disappears. For a persistent tunnel, configure it as a systemd service (cloudflared service install) or use screen / tmux so the process survives disconnection.
In summary: choosing the right option
The ServOrbit subdomain is the default choice if your VPS is with ServOrbit: no configuration, automatic HTTPS via the installer, reverse DNS included. It covers 90% of startup situations.
Dynamic DNS (deSEC, Afraid.org) is worth it if you manage multiple VPS across different providers, want a more descriptive name, or already have a domain you want to delegate without paying an extra DNS host.
A tunnel (Cloudflare Tunnel, ngrok) is the answer when speed is paramount: a prototype to show within the hour, a webhook to test, an unplanned client demo. The short lifespan is a feature, not a flaw.
When your project gains traction, register your domain and attach it to the VPS — that's the natural next step.
