SSL certificates are no longer optional. Browsers flag HTTP sites as insecure. Search engines penalize them. Users don't trust them. Every application you deploy needs HTTPS, and managing SSL certificates shouldn't be something you think about more than once.
Deploynix handles SSL certificate provisioning, renewal, and management automatically. Whether you need a standard certificate for a single domain, a wildcard certificate for multiple subdomains, or a vanity domain for a quick staging environment, the process is streamlined and largely hands-off.
This guide covers everything you need to know about SSL on Deploynix.
How Let's Encrypt Works (The Quick Version)
Let's Encrypt is a free, automated Certificate Authority that issues domain-validated SSL certificates. When you request a certificate, Let's Encrypt needs to verify that you control the domain. There are two primary methods for this verification.
HTTP-01 Challenge
The most common method. Let's Encrypt asks your server to serve a specific file at a specific URL on your domain. If the file is accessible, you've proven you control the domain. This happens automatically — Deploynix places the challenge file, Let's Encrypt verifies it, and the certificate is issued.
Advantages: Simple, fully automatic, works with any domain.
Limitations: Requires port 80 to be open and the domain's DNS to point to your server. Cannot issue wildcard certificates.
DNS-01 Challenge
Let's Encrypt asks you to create a specific DNS TXT record for your domain. If the record exists, you've proven you control the domain's DNS. This method is required for wildcard certificates.
Advantages: Can issue wildcard certificates, works even if port 80 is blocked, works before DNS fully propagates.
Limitations: Requires DNS API access for automation.
Deploynix supports both methods. For standard single-domain certificates, HTTP-01 is used automatically. For wildcard certificates, DNS-01 is used with integrated support for four DNS providers.
Standard SSL Certificates
The most common scenario: you have a domain (or subdomain) pointing to your server, and you need an SSL certificate for it.
Setup Process
Add a site to your server on Deploynix
Point your domain's DNS A record to your server's IP address
Request a Let's Encrypt certificate through the Deploynix dashboard
That's it. Deploynix handles the ACME challenge, certificate issuance, web server configuration (Nginx or Apache), and HTTPS redirect setup. Your site is serving over HTTPS within minutes.
What Deploynix Configures
When an SSL certificate is provisioned, Deploynix automatically:
Installs the certificate and private key in the correct location
Configures your web server (Nginx or Apache) with modern TLS settings (TLS 1.2 and 1.3)
Sets up HTTP-to-HTTPS redirect so all traffic is encrypted
Configures HSTS headers for additional security
Sets appropriate SSL cipher suites and protocols
Backs up the certificate and private key (encrypted) to the database for restoration during server reinstalls or migrations
You don't need to touch web server configuration files. The SSL setup follows current security best practices, which are updated as recommendations evolve.
Automatic Renewal
Let's Encrypt certificates are valid for 90 days. Deploynix handles renewal automatically — certificates are renewed 30 days before expiration, giving ample buffer for any transient issues. If a renewal fails, it retries. You receive a notification if intervention is needed, but in practice, renewals are hands-off.
You never need to set a calendar reminder, write a cron job, or manually renew a certificate. It just works.
Wildcard SSL Certificates
Wildcard certificates cover a domain and all its subdomains with a single certificate. A wildcard certificate for *.example.com covers app.example.com, api.example.com, staging.example.com, and any other subdomain — without needing to issue individual certificates for each.
When You Need Wildcards
Wildcard certificates are useful when:
You run multiple subdomains on the same server
You dynamically create subdomains (multi-tenant SaaS applications)
You want to simplify certificate management for a domain with many subdomains
You need to cover subdomains before their DNS records exist
DNS Validation Requirement
Wildcard certificates require DNS-01 validation. This means Deploynix needs API access to your DNS provider to create the verification TXT records automatically. Deploynix supports DNS validation through four providers:
Cloudflare — The most popular choice. If your domain's DNS is managed through Cloudflare, you provide your Cloudflare API token and Deploynix handles the rest. Cloudflare's API is fast and reliable, making it the recommended option.
DigitalOcean — If your domain's DNS is hosted on DigitalOcean, you can use your DigitalOcean API token for DNS validation. Convenient if you're already using DigitalOcean for hosting.
AWS Route 53 — For domains managed through AWS Route 53. Provide your AWS credentials with Route 53 permissions and Deploynix creates the validation records automatically.
Vultr — If your DNS is managed through Vultr, their API can be used for DNS validation.
Provisioning a Wildcard Certificate
Ensure your domain's DNS is managed by one of the supported providers
Add your DNS provider credentials to Deploynix
Request a wildcard certificate for
*.yourdomain.comDeploynix creates the DNS TXT record, completes validation, and issues the certificate
The wildcard certificate is then available for any subdomain you configure on that server. Add a new subdomain site and it's automatically covered by the existing wildcard — no additional certificate issuance needed.
Wildcard Renewal
Wildcard certificates renew through the same DNS validation process. Deploynix creates a fresh TXT record, Let's Encrypt validates it, and the certificate renews. This happens automatically 30 days before expiration, just like standard certificates.
Vanity Domains (*.deploynix.cloud)
Every site created on Deploynix automatically receives a vanity subdomain under deploynix.cloud. If you create a site, it's immediately accessible at a *.deploynix.cloud URL with SSL included — no domain configuration, no DNS setup, no certificate provisioning.
How Vanity Domains Work
Deploynix maintains a wildcard SSL certificate for *.deploynix.cloud. When you create a site, a unique subdomain is assigned (typically based on your site name or a generated identifier). The DNS for this subdomain points to your server, and the wildcard certificate covers it immediately.
This is handled transparently. You don't need to configure anything — the vanity domain is available as soon as your site is created.
Use Cases for Vanity Domains
Staging environments. Spin up a staging site and share the your-project.deploynix.cloud URL with your team or client. No need to buy a domain, configure DNS, or wait for propagation.
Client previews. Building a site for a client? Share the vanity URL for review before the production domain is configured. The client sees a working site with HTTPS, which builds confidence.
Development environments. Test webhooks, OAuth callbacks, and other features that require a publicly accessible HTTPS URL. The vanity domain provides this without tunneling tools.
Quick demos. Need to show something to a colleague or stakeholder? The vanity domain gives you a shareable, secure URL immediately.
Vanity Domain to Production Domain
When you're ready to go live with a custom domain:
Point your domain's DNS to your server
Add the custom domain to your site on Deploynix
Provision an SSL certificate for the custom domain
The vanity domain continues to work alongside your custom domain, or you can remove it. There's no disruption during the transition.
Custom SSL Certificates
While Let's Encrypt handles the vast majority of SSL needs, there are scenarios where you need to use a custom certificate — an EV (Extended Validation) certificate, a certificate from a specific CA required by corporate policy, or a certificate obtained through a separate process.
Deploynix supports custom certificate installation. Upload your certificate file, private key, and optionally a certificate chain, and Deploynix configures your web server to use them. Custom certificates are backed up (encrypted) in the database just like Let's Encrypt certificates, so they're preserved during server migrations. Custom certificates are not auto-renewed (since Deploynix doesn't control their issuance), so you'll need to track expiration and update them manually.
SSL Configuration Details
Deploynix configures SSL with security best practices that evolve over time. Here's what the current configuration includes.
TLS Versions
TLS 1.2 and TLS 1.3 are enabled. TLS 1.0 and 1.1 are disabled — they have known vulnerabilities and are no longer supported by modern browsers.
Cipher Suites
Modern cipher suites are configured with a preference for forward secrecy. This means that even if a private key is compromised in the future, past communications can't be decrypted.
HSTS (HTTP Strict Transport Security)
HSTS headers tell browsers to always use HTTPS for your domain, even if someone types http:// in the address bar. This prevents downgrade attacks and ensures all connections are encrypted.
OCSP Stapling
OCSP stapling is enabled, which improves SSL handshake performance by bundling the certificate's revocation status with the handshake rather than requiring the browser to check separately.
Troubleshooting SSL Issues
Even with automation, SSL issues can occasionally arise. Here are the most common scenarios and their solutions.
Certificate Issuance Fails (HTTP-01)
Symptom: Certificate request fails with a validation error.
Common causes:
DNS A record doesn't point to the server's IP address
DNS propagation hasn't completed (can take up to 48 hours)
Port 80 is blocked by a firewall
A CDN or proxy is intercepting the validation request
Solution: Verify your DNS A record points to the correct IP. Ensure port 80 is open in your Deploynix firewall rules. If using Cloudflare as a proxy, temporarily set the DNS record to "DNS only" (grey cloud) during issuance.
Wildcard Certificate Issuance Fails
Symptom: Wildcard certificate request fails.
Common causes:
DNS provider credentials are incorrect or lack necessary permissions
The DNS provider API is experiencing issues
The domain's nameservers don't match the DNS provider
Solution: Verify your DNS API credentials. Ensure the domain is actually using the DNS provider's nameservers. Check that the API token has permissions to create TXT records.
Certificate Renewal Fails
Symptom: You receive a notification about a failed renewal.
Common causes:
DNS has been changed since initial issuance
DNS provider credentials have been rotated or revoked
Port 80 is now blocked
Solution: Check that the conditions for initial issuance are still met. Update credentials if they've changed. Deploynix will retry renewal automatically, so fixing the underlying issue is usually sufficient.
Mixed Content Warnings
Symptom: Browser shows a "mixed content" warning despite having SSL.
Cause: Your application is loading resources (images, scripts, stylesheets) over HTTP instead of HTTPS.
Solution: This is an application issue, not a server issue. For Laravel applications, ensure APP_URL uses https:// and use asset() and url() helpers which respect the application URL. For any framework, check for hardcoded http:// URLs in your templates.
SSL and Load Balancers
If you're using a Deploynix Load Balancer server, SSL can be terminated at the load balancer level. This means:
The SSL certificate is installed on the load balancer
Traffic between the user and the load balancer is encrypted
Traffic between the load balancer and your application servers can be unencrypted (internal network)
Deploynix can also sync the load balancer's certificate to backend servers automatically, so backends can serve HTTPS directly if needed
This simplifies certificate management for multi-server setups and reduces SSL handshake overhead on application servers.
Best Practices
Here's a summary of SSL best practices on Deploynix:
Use Let's Encrypt for most cases. It's free, automatic, and trusted by all browsers. Custom certificates are only needed for specific organizational requirements.
Use wildcard certificates for multi-subdomain setups. If you have more than two or three subdomains, a wildcard is simpler than individual certificates.
Use Cloudflare for DNS validation. Cloudflare's API is the fastest and most reliable for DNS-01 challenges. Even if you don't use Cloudflare as a CDN, it's worth using for DNS management.
Use vanity domains for non-production environments. Don't spend time configuring domains and certificates for staging or preview environments. The vanity domain gives you HTTPS immediately.
Monitor your email for renewal notifications. Renewals are automatic, but if one fails, you want to know before the certificate expires.
Ensure your application uses HTTPS URLs. SSL on the server doesn't help if your application generates HTTP links. For Laravel, set
APP_URLcorrectly and use URL helpers. For other frameworks, configure your base URL accordingly.
Conclusion
SSL certificate management is one of those tasks that shouldn't require ongoing attention. Provision it once, let it renew automatically, and forget about it. Deploynix makes this the reality — standard certificates provision in minutes, wildcard certificates work through DNS API integration, vanity domains provide instant HTTPS, and renewals happen automatically.
Whether you're running a single-domain application or a multi-tenant SaaS platform with dozens of subdomains, Deploynix handles the SSL complexity so you can focus on building your application. And with encrypted certificate backups stored in the database, your certificates survive server migrations and reinstalls without manual intervention.
Get started at https://deploynix.io.
Top comments (0)