Setting Up Custom Domains on Deploynix: A Complete Walkthrough

Your Laravel application is deployed, your code is running smoothly, and your site is accessible through a Deploynix vanity domain like yourapp.deploynix.cloud. Now it is time to make it professional with your own custom domain. Setting up a custom domain involves configuring DNS records, waiting for propagation, provisioning an SSL certificate, and verifying everything works correctly.

This guide walks you through every step of the process, explains the concepts behind each decision, and helps you troubleshoot the common pitfalls that trip up developers who are not DNS experts.

Understanding DNS Basics

Before configuring anything, let's establish a foundation. DNS, the Domain Name System, is essentially the phone book of the internet. When someone types yourapp.com into their browser, DNS translates that human-readable domain name into the IP address of your server.

The key DNS record types you will work with are:

A Record — Maps a domain name directly to an IPv4 address. For example, yourapp.com → 123.45.67.89. This is the most common record type for pointing a domain to a server.

AAAA Record — The same as an A record but for IPv6 addresses.

CNAME Record — Maps a domain name to another domain name (an alias). For example, www.yourapp.com → yourapp.com. The browser then resolves the target domain to get the IP address.

Important distinction: A root domain (also called an apex domain or naked domain, like yourapp.com without any subdomain) cannot use a CNAME record according to the DNS specification. Root domains must use A records. Subdomains like www.yourapp.com or app.yourapp.com can use either A or CNAME records.

Step 1: Get Your Server's IP Address

First, find the IP address of your Deploynix server. Log in to the Deploynix dashboard, navigate to your server, and note the public IPv4 address displayed on the server overview page.

If you are running a load-balanced setup with a Deploynix load balancer, use the load balancer's IP address instead of any individual app server's IP. The load balancer will distribute traffic to your app servers using your configured method, whether that is Round Robin, Least Connections, or IP Hash.

Step 2: Configure DNS Records

Log in to your domain registrar or DNS provider. This is wherever you manage your domain's DNS settings. Common providers include Cloudflare, Namecheap, GoDaddy, Google Domains, and Route 53.

For a Root Domain (yourapp.com)

Create an A record:

| Type | Name | Value | TTL |

|------|------|-------|-----|

| A | @ | 123.45.67.89 | 300 |

The @ symbol represents the root domain. The TTL (Time to Live) of 300 seconds (5 minutes) means DNS resolvers will cache this record for 5 minutes before checking for updates. During initial setup, a low TTL is helpful because it means changes take effect quickly.

For www Subdomain (www.yourapp.com)

You have two options:

Option A: CNAME record pointing to the root domain

| Type | Name | Value | TTL |

|------|------|-------|-----|

| CNAME | www | yourapp.com | 300 |

This is the preferred approach because if your server IP changes, you only need to update the A record on the root domain. The www CNAME automatically follows.

Option B: A record pointing to the server IP

| Type | Name | Value | TTL |

|------|------|-------|-----|

| A | www | 123.45.67.89 | 300 |

This works but means you need to update two records if your server IP changes.

For a Subdomain (app.yourapp.com)

If your application lives on a subdomain, create an A record or CNAME:

| Type | Name | Value | TTL |

|------|------|-------|-----|

| A | app | 123.45.67.89 | 300 |

Or use a CNAME if you have a canonical domain to point to.

Using Cloudflare

If you use Cloudflare as your DNS provider (which many Deploynix users do for its additional security and performance features), there is an important consideration: Cloudflare's proxy feature.

When the orange cloud icon is enabled (proxy on), Cloudflare routes traffic through its network before forwarding it to your server. This provides DDoS protection and caching but can interfere with SSL certificate provisioning if Deploynix needs to verify domain ownership via HTTP challenges.

During initial SSL provisioning, you may need to temporarily set the record to "DNS only" (grey cloud) so that traffic goes directly to your server. Once the SSL certificate is provisioned, you can re-enable the proxy.

Cloudflare also provides a feature called CNAME flattening, which allows you to use CNAME-like behavior on the root domain. This is a Cloudflare-specific feature and is not standard DNS.

Step 3: Wait for DNS Propagation

After creating your DNS records, they need to propagate across the global DNS network. This means DNS resolvers around the world need to learn about your new records.

Propagation time varies:

• New records typically propagate within minutes to a few hours

• Changed records depend on the previous TTL value. If the old TTL was 86400 (24 hours), some resolvers may cache the old record for up to 24 hours

• Worst case is usually 48 hours, though this is rare with modern DNS infrastructure

You can check propagation status using command-line tools:

# Check A record resolution
dig yourapp.com A +short

# Check from a specific DNS server (Google's public DNS)
dig @8.8.8.8 yourapp.com A +short

# Check CNAME resolution
dig www.yourapp.com CNAME +short

Or use online tools like dnschecker.org to verify propagation across multiple geographic locations simultaneously.

Do not proceed to SSL provisioning until your DNS records are resolving correctly. If the DNS is not pointing to your Deploynix server, SSL verification will fail.

Step 4: Add the Domain in Deploynix

With DNS configured and propagating, add your custom domain to your site in the Deploynix dashboard.

Navigate to your server, select your site, and go to the domain settings. Add your custom domain (for example, yourapp.com). If you want both the root domain and www to work, add both yourapp.com and www.yourapp.com.

Deploynix will update the Nginx server configuration to respond to requests for your custom domain. This is important because Nginx uses server blocks (similar to Apache's virtual hosts) to determine which site configuration handles each incoming request. Without adding the domain in Deploynix, Nginx will not know to route traffic for yourapp.com to your site.

Step 5: Provision an SSL Certificate

Every modern website needs HTTPS. Not only does it encrypt traffic between your users and your server, but browsers increasingly penalize HTTP-only sites, and search engines factor HTTPS into rankings.

Deploynix supports automatic SSL certificate provisioning. When you add a custom domain, you can request an SSL certificate for it.

HTTP Challenge Verification

The most common SSL provisioning method is the HTTP challenge. The certificate authority (Let's Encrypt) sends a request to your domain to verify you control it. This requires:

1. Your DNS records are pointing to your Deploynix server

2. Port 80 (HTTP) is open on your server's firewall

3. No proxy (like Cloudflare's orange cloud) is intercepting the verification request

If the HTTP challenge succeeds, your certificate is issued within seconds.

DNS Challenge Verification

For domains behind a CDN proxy, or when you need wildcard certificates, the DNS challenge is the alternative. Instead of verifying via HTTP, the certificate authority checks for a specific DNS TXT record.

Deploynix supports DNS verification through several DNS providers: Cloudflare, DigitalOcean, AWS Route 53, and Vultr. If your DNS is managed by one of these providers, Deploynix can automatically create and clean up the verification TXT records.

To use DNS verification, connect your DNS provider credentials in the Deploynix dashboard. Then, when provisioning an SSL certificate, select the DNS challenge method.

Certificate for Multiple Domains

If your site responds to both yourapp.com and www.yourapp.com, your SSL certificate needs to cover both domains. Deploynix handles this automatically when both domains are added to your site configuration. The certificate will include both domains as Subject Alternative Names (SANs).

Step 6: Configure Redirects

With both the root domain and www configured, you should set up a redirect so that one canonical version is used. This prevents duplicate content issues for SEO and provides a consistent experience for users.

The most common convention is to redirect www.yourapp.com to yourapp.com (dropping the www). Some teams prefer the opposite. Either way, pick one and be consistent.

Deploynix can handle this redirect at the Nginx level, which is more efficient than handling it in your Laravel application because the redirect happens before PHP is even involved.

In your Laravel application, update the APP_URL environment variable to match your canonical domain:

APP_URL=https://yourapp.com

This ensures all URLs generated by Laravel's url() and route() helpers use the correct domain.

Step 7: Verify Everything Works

With DNS, SSL, and redirects configured, run through this verification checklist:

DNS Verification

# Root domain resolves to your server
dig yourapp.com A +short
# Should return your server's IP

# www resolves correctly
dig www.yourapp.com +short
# Should return your server's IP (directly or via CNAME)

SSL Verification

# Check SSL certificate
curl -vI https://yourapp.com 2>&1 | grep -A 5 "SSL certificate"

# Or use openssl
echo | openssl s_client -connect yourapp.com:443 -servername yourapp.com 2>/dev/null | openssl x509 -noout -dates

Redirect Verification

# Check www redirects to root (or vice versa)
curl -I http://www.yourapp.com
# Should return 301 redirect to https://yourapp.com

# Check HTTP redirects to HTTPS
curl -I http://yourapp.com
# Should return 301 redirect to https://yourapp.com

Application Verification

Open https://yourapp.com in your browser and verify:

• The site loads correctly

• The SSL padlock icon appears in the address bar

• Links within the application use the correct domain

• Assets (CSS, JavaScript, images) load without mixed content warnings

• Login and form submissions work correctly

Troubleshooting Common Issues

SSL Certificate Fails to Provision

DNS not pointing to your server. Verify with dig that your domain resolves to your Deploynix server's IP. If you recently changed DNS records, wait for propagation.

Firewall blocking port 80. The HTTP challenge requires port 80 to be open. Check your Deploynix firewall rules.

Cloudflare proxy interfering. If using Cloudflare, temporarily disable the proxy (grey cloud) for the HTTP challenge.

Rate limiting. Let's Encrypt has rate limits. If you have requested too many certificates for the same domain recently, you may need to wait before trying again.

Site Shows "Welcome to Nginx" Page

Your domain is resolving to the server, but Nginx does not know which site to serve. This means the domain has not been added to your site configuration in Deploynix. Add the domain in the Deploynix dashboard.

Mixed Content Warnings

Your page loads over HTTPS, but some assets are being loaded over HTTP. This typically happens when your APP_URL environment variable is set to http:// instead of https://, or when you have hardcoded http:// URLs in your templates. Update APP_URL to use HTTPS and check your templates for hardcoded URLs.

Redirect Loop

If your browser shows "too many redirects," there is likely a conflict between your application's redirect logic and Cloudflare's SSL settings. If using Cloudflare, set the SSL mode to "Full (strict)" rather than "Flexible." Flexible mode means Cloudflare connects to your server over HTTP, and your server redirects HTTP to HTTPS, which creates an infinite loop.

Increasing TTL After Verification

Once everything is working correctly, increase your DNS TTL to reduce DNS query load and improve resolution speed for your users:

| Type | Name | Value | TTL |

|------|------|-------|-----|

| A | @ | 123.45.67.89 | 3600 |

A TTL of 3600 (1 hour) is a good balance between caching efficiency and flexibility. Some teams use 86400 (24 hours) for stable production domains.

Conclusion

Setting up a custom domain on Deploynix is a straightforward process once you understand the concepts. Configure your DNS records to point to your server, add the domain in Deploynix, provision an SSL certificate, set up redirects, and verify everything works. The most common issues, including failed SSL provisioning, redirect loops, and mixed content warnings, all have clear solutions.

With your custom domain configured, your application presents a professional face to the world. Combined with Deploynix's automatic SSL renewal and zero-downtime deployments, you can focus on building features rather than managing infrastructure. Take the time to verify every step, set sensible TTL values, and document your DNS configuration for your team. A well-configured domain setup is something you do once and rarely think about again.