Custom domains and HTTPS
Which lane you are on decides whether this page applies to you.
Bring Your Own Server - available today. You give us the hostname you have pointed at your own box, we check the DNS resolves to it before installing anything, and the certificate is issued and renewed for you. Everything below describes what actually happens.
Shared - not available. Your instance runs on its own yourname.splicerun.com
address, with HTTPS issued and renewed automatically, and there is no way to put a
domain of your own in front of it yet. Your dashboard does not show an instance IP
address, so there is nothing to point a record at.
Dedicated - not available. The server side would honour a domain, but nothing in the
dashboard lets you set one, so in practice you get a splicerun.com address like Shared.
Your instance runs on a domain you choose. This page explains how to point it, what happens automatically, and why the order of steps matters.
What you need
- A domain or subdomain you control - anything you can add a DNS record to
- The ability to add an A record at your DNS provider
That's it. You don't need to buy a certificate, install anything, or configure a web server.
Point the domain at your instance
Add a single A record at your DNS provider pointing your chosen hostname at your instance's IP address:
| Field | Value |
|---|---|
| Type | A |
| Name | The subdomain you want (e.g. automation, or @ for the root domain) |
| Value | Your instance's IP address, shown in your dashboard |
| TTL | Default is fine |
A subdomain like automation.yourcompany.com is the usual choice - it keeps your main
website untouched.
What happens automatically
Once the domain resolves to your instance, HTTPS is handled for you:
- A certificate is issued automatically from Let's Encrypt the first time your domain is reachable
- It is renewed automatically before expiry - there is no cron job for you to run and no renewal date for you to track
- HTTP traffic is redirected to HTTPS
You do not need to supply a certificate, and there is nothing to configure.
Why DNS has to come first
Certificate issuance works by proving you control the domain. The certificate authority requests a specific file over HTTP on port 80 at your hostname - so the domain has to already resolve to your instance, and port 80 has to be reachable, before a certificate can be issued.
This is why setup checks DNS before it runs, rather than after. If the domain isn't pointing at the right place yet, issuing a certificate is impossible, not merely slow.
DNS propagation
DNS changes are not instant. A new record usually resolves within a few minutes but can take up to a few hours depending on your provider and the TTL on any previous record.
If you're changing an existing record rather than creating a new one, lower its TTL a day beforehand if you can - the old value is cached for however long the old TTL said.
Ports that must be open
| Port | Used for |
|---|---|
| 80 | Certificate issuance and renewal, then redirect to HTTPS |
| 443 | Your actual traffic |
Port 80 has to stay open permanently, not just during setup - renewals use it too. Closing it after setup is a common cause of a certificate that works for a few weeks and then fails.
Changing your domain later
Contact support before changing it. Repointing DNS on a live instance means a new certificate has to be issued for the new hostname, and sequencing it properly avoids a window where the old name is broken and the new one isn't ready yet.
If something goes wrong
See Custom domain SSL certificate won't renew for the specific failure cases and what each one means.
Stuck? Contact Support - we'll check what your domain is actually resolving to and tell you what we see.