SSL Certificates

Deploynix issues, renews, and rotates TLS certificates for every site — free Let's Encrypt by default, wildcards via your DNS provider, and custom uploads when you bring your own.

Overview

SSL is managed per site from the SSL Certificates tab on the site's detail page. Every server already ships with a system-managed vanity wildcard certificate at provisioning time, so new sites are reachable over HTTPS immediately on their *.deploynix.cloud subdomain. For custom domains, you create a real certificate in three clicks — Let's Encrypt handles the rest.

The Four Certificate Types

Deploynix manages four kinds of certificates. Knowing which one you want up front makes the rest of this page straightforward.

The Per-Site SSL Tab

Open a site and click SSL Certificates. The tab shows a table of every certificate currently attached to the site with its domain, type, expiry date, and a status badge. Status values you'll see:

• Pending — the issue / install job is queued or running.
• Active — the certificate is installed in Nginx and serving HTTPS.
• Failed — issuance or installation hit an error. The row shows the failure reason; fix it and retry from the same row.

A certificate that's expiring within 30 days is flagged in the UI so you have time to react if auto-renewal ever fails. Wildcard certs are marked with a wildcard badge, and a certificate attached to more than one site shows a "shared" indicator so you don't accidentally remove it from under another site.

Click Add Certificate to open the issuance modal. The fields you see adapt to the type you pick:

• Type — Let's Encrypt or Custom.
• Domain — the hostname to secure. For wildcards enter *.example.com and the apex will be included automatically.
• DNS provider — only shown for wildcards; pick one you've already connected under Settings → DNS Providers.
• Custom PEM fields — certificate, private key, and optional chain textareas, shown only when you pick Custom.

Let's Encrypt — HTTP Challenge

For a single hostname, HTTP-01 is the fastest path. Deploynix runs certbot on the server with the webroot plugin — it writes a temporary challenge file under /.well-known/acme-challenge, Let's Encrypt fetches it over port 80, and the cert is issued typically within 10–30 seconds. Nginx is reloaded gracefully so existing connections aren't interrupted.

Let's Encrypt — Wildcard via DNS

Wildcard certificates can't be issued over HTTP — Let's Encrypt requires the DNS-01 challenge. Deploynix automates it end to end: it creates a temporary _acme-challenge TXT record on your DNS provider via API, waits for propagation, proves control, and removes the record when certbot is done.

Supported DNS Providers

• Cloudflare — API token
• DigitalOcean — API token
• AWS Route 53 — access key ID, secret access key, region
• Vultr — API key

For the exact scopes and API key setup for each provider, see the Provider Permissions reference.

Setup

1. Open Settings → DNS Providers and click Add Provider.
2. Pick the provider and enter its credentials. They're encrypted at rest.
3. On the site's SSL Certificates tab, click Add Certificate, pick Let's Encrypt, set the domain to *.example.com, pick the DNS provider, and request.

The resulting certificate covers both the wildcard and the apex, and can be attached to any number of sites whose hostnames match it.

Custom / Uploaded Certificates

Use a custom certificate when you have an EV cert, a cert from corporate PKI, an existing purchased cert, or a hostname on a private domain you can't validate over Let's Encrypt. On the issuance modal, pick Custom and paste:

• Certificate (PEM) — the leaf certificate.
• Private Key (PEM) — the matching key.
• Certificate Chain — any intermediate certificates, optional but usually required for browsers to trust the cert.

Automatic Renewal

Every Let's Encrypt certificate has an auto_renew flag that's on by default. A scheduled task runs daily and renews every certificate whose expires_at is within 30 days — it re-runs the same validation flow (HTTP-01 or DNS-01), installs the new cert, and reloads Nginx gracefully. Because renewal happens weeks before expiry, a one-off failure never takes down HTTPS — Deploynix has plenty of time to retry.

When renewal fails, a CertRenewalFailedNotification is sent to the organization so you see it immediately. The Renew action on the SSL tab lets you force an immediate renewal attempt for debugging — handy when you've just fixed a DNS provider credential and want to retry now rather than wait for the next scheduled pass.

Custom certificates never auto-renew. Treat the 30-day expiry warning in the UI as your cue to regenerate and re-upload.

The Vanity Wildcard Certificate

Every App, Web, Database, Cache, and Meilisearch server gets a copy of a system-managed wildcard certificate covering *.deploynix.cloud installed at provisioning time. Every new site is assigned a unique subdomain on that wildcard, so you can open the site over HTTPS the moment it's ready — before you've configured real DNS. It's also what secures the server's built-in admin endpoints.

You don't manage this certificate. Deploynix issues it once on the application server, stores the fullchain and private key encrypted in its database, and syncs the same pair to every managed server during provisioning. A daily scheduled task renews it 30 days before expiry and re-syncs to all servers automatically. Operators can trigger the flow manually via vanity:issue-certificate and vanity:sync-certificate artisan commands, but end users never need to.

Adopting Existing Certificates

If a server already has valid certificates — because you migrated from another tool or installed certbot before connecting the server to Deploynix — the SSL tab will offer to adopt them instead of re-issuing. Confirm, and the existing fullchain and key are read from disk, encrypted into the database, attached to the site, and wired into the site's Nginx config going forward. Scheduled renewal then takes over just as it would for a freshly issued cert.

If you'd rather start clean, reject the adoption prompt and issue a new certificate — just mind the Let's Encrypt rate limits if the existing cert is also from Let's Encrypt.

Replacement & Rotation

Use Replace on an existing row to rotate without downtime. Deploynix installs the new certificate alongside the old one, validates it, then flips Nginx to the new cert with a graceful reload — no in-flight connections are dropped. If the install fails, the old certificate stays in place and the site keeps serving HTTPS.

Remove detaches a certificate from a site and reverts Nginx for that hostname. Certificates shared with other sites stay installed on disk until the last site stops using them — removing one site from a shared cert never breaks another.

Multiple Domains on One Certificate

• Wildcard — one *.example.com + apex certificate can secure unlimited subdomains on the same root. Sites whose primary domain lands under the same root can share a single wildcard cert.
• Custom multi-SAN — if you upload a certificate with multiple Subject Alternative Names, Deploynix will match any of those names to the sites using them.
• HTTP-01 Let's Encrypt — each hostname is its own certificate. To secure example.com and www.example.com with HTTP-01, issue two certificates, or switch to a wildcard via DNS-01.

Nginx SSL Defaults

When a certificate lands on a site, Deploynix rewrites the site's Nginx config with secure defaults:

• TLS 1.2 and TLS 1.3 only — older protocols are disabled.
• Modern cipher suite — AEAD ciphers prioritized.
• HSTS — HTTP Strict Transport Security header.
• OCSP stapling — faster certificate verification for clients.
• HTTP to HTTPS redirect — port 80 traffic is redirected to HTTPS automatically.

Troubleshooting

HTTP-01 Fails

• DNS — confirm the domain resolves to the server's IP (dig +short example.com).
• Propagation — recent DNS changes can take up to 48 hours to propagate globally.
• Firewall — port 80 must be reachable from the public internet, even if you only serve on 443.
• Rate limits — if you've been retrying in a loop, wait; the limits reset weekly.

DNS-01 Fails with "TXT record not found"

• Your DNS provider credentials may have expired or been rotated — re-check them under Settings → DNS Providers.
• Wait a minute for propagation, then retry — some providers can take 30–90 seconds to serve a new TXT record globally.
• Confirm the DNS provider you selected is actually authoritative for the root domain you're trying to issue against.

Certificate Chain Issues in Browsers

• Include every intermediate certificate in the chain field when uploading a custom cert.
• Order matters: leaf first, then intermediates, in the correct chain order.
• Verify the leaf matches the domain you're installing it on.

Renewal Silently Failing

Check your organization's notifications — CertRenewalFailedNotification lands there on every failed renewal. The most common causes are DNS provider credentials that expired, a DNS record that was manually deleted, or port 80 being blocked after a firewall change.