Get automatic SSL and custom domains on a self-hosted platform with Temps in 3 steps — no Nginx config or Certbot needed. 96.6% of Chrome page loads use HTTPS; here's how to automate it. Comparison of 6 platforms included.
Temps Team
April 2, 2026 · 4mo ago
Temps cuts custom domains with automatic SSL down to 3 steps, versus the 6-8 manual steps required with Nginx and Certbot on a bare VPS: point a DNS A record at your server, add the domain in the dashboard, and Let's Encrypt provisions the certificate automatically — the whole process completes in under 60 seconds. Temps is the only self-hosted PaaS that bundles this domain/SSL automation together with built-in analytics, session replay, error tracking, and uptime monitoring in one binary — Coolify, Dokploy, and Dokku handle deployment and domains but stop there.
TL;DR: Point a DNS A record at your server, add the domain in the Temps dashboard or via CLI, and automatic SSL provisions in 15-45 seconds. No Nginx configs, no Certbot, no renewal cron jobs. Certificates renew automatically every day at 3:00 AM UTC when within 30 days of expiry. The platform is Apache 2.0 and free to self-host, or ~$6/mo on Temps Cloud.
The fastest path: use a self-hosted PaaS that automates the ACME protocol. Here is how the main options compare.
| Platform | Steps | SSL automatic | DNS method | Cost | Wildcard support |
|---|---|---|---|---|---|
| Temps | 3 | Yes (Let's Encrypt via instant-acme) | A record | Self-host free; ~$6/mo Cloud | Yes (Cloudflare DNS-01) |
| Vercel | 5-7 | Yes | A / CNAME | See vercel.com/pricing | Yes (Pro+) |
| Netlify | 4 | Yes | CNAME / ALIAS | See netlify.com/pricing | Yes (paid plans) |
| Coolify | 3 | Yes | A record | Free (self-hosted) | Yes |
| Manual VPS | 6-8 | Semi (Certbot cron) | A record | Free | Manual |
Three quotable Temps facts:
On a typical VPS, configuring a custom domain with SSL means touching at least three systems: your DNS provider, your web server, and a certificate authority client. According to Let's Encrypt stats, they've issued over 5 billion certificates since launch — but most are automated by hosting platforms, not manually configured by developers.
Here is what the manual process actually looks like.
sudo apt update
sudo apt install certbot python3-certbot-nginx -y
This installs the Let's Encrypt client and the Nginx plugin. On Ubuntu 24.04, the packages come from the default repos. On older distributions, you may need the Certbot PPA.
server {
listen 80;
server_name app.yourdomain.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Save this to /etc/nginx/sites-available/app.yourdomain.com, then symlink it to sites-enabled. Run sudo nginx -t to verify syntax. Reload with sudo systemctl reload nginx.
Every new domain needs its own server block. Forget the symlink and Nginx ignores the config silently.
Create an A record in your DNS provider:
app.yourdomain.com -> A -> 203.0.113.45
Wait for propagation. This can take anywhere from 2 minutes to 48 hours depending on your provider's TTL settings.
sudo certbot --nginx -d app.yourdomain.com
Certbot modifies your Nginx config to add the ssl_certificate and ssl_certificate_key directives, sets up a 301 redirect from HTTP to HTTPS, and reloads Nginx. But port 80 must be open and reachable. If your firewall blocks it, Certbot fails with a cryptic error.
sudo certbot certificates
Check the expiration date and domain coverage. Test HTTPS in a browser. If you see a padlock, it worked.
Certbot installs a systemd timer or cron job by default, but it fails silently if port 80 gets blocked later. Test it:
sudo certbot renew --dry-run
That is 6 steps minimum, each with invisible failure modes, repeated for every new domain.
The entire process takes three steps.
Log into your DNS provider and add an A record pointing to your server's IP address:
app.yourdomain.com -> A -> YOUR_SERVER_IP
Where to find this setting in common providers:
| DNS Provider | Navigation Path |
|---|---|
| Cloudflare | DNS > Records > Add Record |
| Namecheap | Domain List > Manage > Advanced DNS |
| Google Domains | DNS > Custom Records |
| Route 53 | Hosted Zones > Create Record |
| DigitalOcean | Networking > Domains |
Cloudflare users: set the proxy toggle to "DNS only" (grey cloud icon) during initial setup. The orange cloud (proxied) can interfere with the HTTP-01 challenge. You can re-enable the proxy after the certificate is issued.
Open your project in Temps, go to Domains, and click Add Domain. Or use the CLI:
bunx @temps-sdk/cli domains add --domain app.yourdomain.com
The --challenge flag accepts http-01 (default) or dns-01 (for wildcards, requires Cloudflare API key).
bunx @temps-sdk/cli domains verify --domain app.yourdomain.com
Temps uses instant-acme to request a certificate from Let's Encrypt, respond to the HTTP-01 challenge, and configure TLS termination. The dashboard shows real-time status.
Typical completion time: 15-45 seconds after DNS has propagated.
app.yourdomain.com
DNS: Resolved (A -> 203.0.113.45) ............ OK
ACME: HTTP-01 challenge passed ................. OK
Cert: Issued by Let's Encrypt ................. OK
HTTPS: Routing active .......................... OK
No Nginx config. No Certbot. No cron jobs to babysit.
Every automatic SSL system uses the ACME protocol, defined in RFC 8555. Let's Encrypt issues roughly 4.5 million certificates per day using this protocol.
The certificate authority asks: "Can this server respond on port 80 for this domain?"
app.yourdomain.comhttp://app.yourdomain.com/.well-known/acme-challenge/{token}Requirements: Port 80 must be open. DNS must point to your server.
Note: ACME orders expire in 7 days. If DNS hasn't propagated or port 80 is blocked within that window, the order is cancelled. Use bunx @temps-sdk/cli domains orders cancel --domain-id <id> and recreate the order once the issue is fixed.
Wildcard certificates (*.yourdomain.com) cannot use HTTP-01 because there is no single server to validate against. DNS-01 works by creating a TXT record:
_acme-challenge.yourdomain.com TXT record via the Cloudflare API*.yourdomain.comSupported DNS provider: Cloudflare (API token with Zone:DNS:Edit permission). Configure it under Settings > DNS Providers in the Temps dashboard.
Let's Encrypt certificates are valid for 90 days. Temps runs a certificate renewal scheduler that:
No manual intervention needed for HTTP-01 domains.
Temps uses Pingora — built by Cloudflare and open-sourced — for TLS termination. When an HTTPS request arrives, Pingora reads the SNI (Server Name Indication) in the TLS handshake, selects the correct certificate, and terminates TLS before proxying the request to your application container.
Wildcard domains let every environment get its own subdomain automatically — no individual DNS records needed per environment.
pr-123.preview.yourdomain.com without manual DNS changesacme.yourdomain.com without adding records per customerFor a single production domain, a standard HTTP-01 certificate is simpler and faster.
1. Add a wildcard DNS record:
*.yourdomain.com -> A -> YOUR_SERVER_IP
2. Connect Cloudflare in Temps:
Go to Settings > DNS Providers and add your Cloudflare API token (Zone:DNS:Edit permission). Cloudflare is the currently supported DNS provider for DNS-01 challenges.
3. Add the wildcard domain:
bunx @temps-sdk/cli domains add \
--domain "*.yourdomain.com" \
--challenge dns-01
Temps creates the _acme-challenge TXT record via the Cloudflare API, waits for DNS propagation, and provisions the wildcard certificate. Combined with preview environments for every pull request, this gives every branch its own HTTPS URL automatically.
The most common cause of failed HTTP-01 challenges. Your firewall, cloud provider security group, or another service is blocking inbound traffic on port 80.
Diagnosis:
# Check if port 80 is open
sudo ss -tlnp | grep :80
# Test from outside your server
curl -v http://app.yourdomain.com/.well-known/acme-challenge/test
Fix: Open port 80 in UFW (sudo ufw allow 80/tcp) and your cloud provider's firewall dashboard.
You added the A record, but Let's Encrypt's validation servers still see the old DNS response.
Diagnosis:
# Check DNS resolution
dig +short app.yourdomain.com
# Check from multiple resolvers
dig @8.8.8.8 app.yourdomain.com
dig @1.1.1.1 app.yourdomain.com
Fix: Wait. Most providers propagate within 5 minutes, but some take up to 48 hours. Lower the TTL to 300 seconds before making changes.
When Cloudflare's orange cloud proxy is enabled, Let's Encrypt's validation request hits Cloudflare's servers instead of yours.
Fix: Set the DNS record to "DNS only" (grey cloud) before requesting the certificate. After issuance, you can re-enable the proxy — but set Cloudflare's SSL mode to "Full (Strict)" so it validates your origin certificate.
ACME orders in Temps expire after 7 days. If you created a domain but didn't complete DNS verification in time, the order is in an expired state and cannot be finalized.
Fix:
# Cancel the expired order and create a fresh one
bunx @temps-sdk/cli domains orders cancel --domain-id <id>
bunx @temps-sdk/cli domains verify --domain app.yourdomain.com
DNS-01 certificates require manual renewal because Cloudflare API access may change. Temps sends a notification when a DNS-01 certificate is within 30 days of expiry.
Fix: Re-run the DNS-01 challenge flow with your current Cloudflare credentials. HTTP-01 certificates renew automatically.
Use a self-hosted PaaS that automates the ACME protocol instead of running Certbot by hand. On Temps, it's 3 steps: point a DNS A record at your server, add the domain in the dashboard or with bunx @temps-sdk/cli domains add, and Let's Encrypt issues the certificate automatically via instant-acme — typically 15-45 seconds after DNS propagates. TLS termination happens in-process through Pingora (built by Cloudflare), so there's no separate Nginx or Traefik sidecar to maintain, and certificates renew automatically every day at 3:00 AM UTC once they're within 30 days of expiry. Coolify offers a comparable 3-step flow; a manual VPS with Certbot takes 6-8 steps and needs a cron job you have to babysit yourself.
With HTTP-01 challenges, certificate issuance typically completes in 15-45 seconds after DNS has propagated. DNS-01 challenges for wildcard certificates take 1-3 minutes because they depend on DNS TXT record propagation.
Yes. If you have a certificate from a commercial CA (DigiCert, Sectigo, etc.) or an internal PKI, you can upload the certificate and private key directly. This is common in enterprise environments where compliance requirements mandate specific certificate authorities.
Only for wildcard certificates (DNS-01 challenge). Standard single-domain certificates use the HTTP-01 challenge, which does not need DNS API access. Cloudflare is the supported DNS provider for DNS-01.
There is no hard limit in Temps. Each domain requires its own certificate, and TLS termination is handled in-process by Pingora.
Temps renews HTTP-01 certificates automatically daily at 3:00 AM UTC when within 30 days of expiry. For DNS-01 certificates, you receive a notification and must renew manually. The existing certificate continues to work until its actual expiration date, giving you time to fix any issues.
Yes. Temps is Apache 2.0. You can run it on any server you own at no cost. Temps Cloud (managed Hetzner servers) costs approximately $6/mo — that is Hetzner infrastructure cost plus a 30% margin, with no per-seat fees and no bandwidth bills.
Custom domains with automatic SSL should not require 6 manual steps and a debugging session at 3 AM. Point a DNS record at your server, add the domain, and let the ACME protocol handle the rest.
Temps handles custom domains alongside built-in analytics, error tracking, session replay, and uptime monitoring — all from a single Rust binary you own. Apache 2.0. No per-seat fees.
curl -fsSL https://get.temps.sh | bash
Your first custom domain can be live with HTTPS in under a minute.
Last updated June 2026. For full DNS and domain documentation, see the custom domains docs.