RE:NODE

Use your own domain on Renode

Put your own domain in front of a RE:NODE app or web server: the proxy slot, the A record, automatic certificates, Cloudflare settings, X-Forwarded-For, and why issuance fails.

All docs pages

App and web plans include a reverse-proxy slot. It accepts requests for your domain on the public address, terminates HTTPS there, and forwards plain HTTP to the one port your app listens on. Certificates are issued and renewed for you. RE:NODE does not sell domains or run DNS, so the records are created wherever your domain's DNS lives.

Adding a domain#

  1. On your server's Proxy tab, add the hostname - for example app.example.com.
  2. At your DNS provider, create an A record for that name pointing at the address the proxy slot shows.
  3. Wait for the name to resolve. Once it does, the certificate is issued automatically.

Renewal runs automatically inside the last 21 days of the certificate's life, so there is nothing to do each year.

NameTypeValue
appAThe address shown on the proxy slot
@ (the apex)AThe address shown on the proxy slot
wwwCNAMEexample.com, or a second A record

Add both names to the proxy slot if both should work - a certificate covers only the names it was issued for. The apex cannot be a CNAME.

Cloudflare#

If your DNS is on Cloudflare, set the record to DNS only (the grey cloud), not proxied. Cloudflare's proxy answers the certificate challenge itself, so the certificate for your server can never be issued, and it only carries HTTP and HTTPS on a fixed list of ports.

What your app sees behind the proxy#

  • Plain HTTP, on its own port. TLS ends at the proxy. An app that redirects every non-HTTPS request to HTTPS will loop for ever - trust the proxy instead. In Express that is app.set("trust proxy", true); in Django, SECURE_PROXY_SSL_HEADER.
  • The visitor's address in `X-Forwarded-For`, not in the connection itself.
  • The domain in `Host`. Frameworks with an allowed-hosts list (Django's ALLOWED_HOSTS, for one) must include it.

Your app still listens on 0.0.0.0 and SERVER_PORT exactly as before - the proxy finds it there.

Game servers and databases#

The proxy slot carries web traffic. A game server is not reached through it: point an A record straight at the server's address and players connect to the game port. Database hosting servers have no proxy slot; apps connect to their address and port directly.

Why a certificate is not issued#

In the order they actually occur:

  1. The name does not resolve here yet. Check with dig +short app.example.com A @1.1.1.1 (or nslookup app.example.com 1.1.1.1 on Windows), not your browser. If the record is right and the answer is old, wait out the record's TTL.
  2. It resolves somewhere else. An old A record from a previous host is still there, or there are two. Delete the old one rather than adding a second.
  3. A stale AAAA record. If the server has no IPv6 address, an AAAA record left from a previous host is tried first and fails. Delete it.
  4. The record is proxied by a CDN. See Cloudflare above.
  5. A CAA record names another certificate authority. Check with dig +short example.com CAA.
  6. Port 80 does not reach the proxy. Validation happens over HTTP on port 80 for that hostname.

Fix the cause, then try once - certificate authorities rate-limit repeated failures.

Questions this does not answer? Open a ticket from the panel, or start from the overview. These pages are also available as plain text for AI assistants at /llms.txt.