How to Deploy a Static Site With a Custom Domain and Automatic HTTPS

Overview

A static site deployment usually has four moving parts: your generated site files, a static hosting platform, your domain’s DNS records, and your HTTPS certificate. If any one of those is misconfigured, the site may partially work, load on one hostname but not another, or fail certificate validation.

The cleanest mental model is this:

• Build output: the folder your static site generator produces, such as dist, build, or public.
• Hosting target: the platform that serves those files at the edge or from object storage.
• Domain connection: DNS records that tell browsers where your domain should resolve.
• Automatic HTTPS: the certificate provisioning step that secures the final hostname.

Before you start, decide three things clearly:

1. Your canonical domain: example.com or www.example.com.
2. Your deployment method: manual upload, Git-based deployment, or CI/CD.
3. Your DNS authority: the provider where your nameservers or zone records are managed.

If you skip these decisions, you usually end up fixing them later under pressure.

For related DNS concepts, see How to Point a Domain to a Server: A Record, CNAME, Nameservers, and TTL Explained. If you expect to automate repeat deployments, it is also worth keeping Terraform DNS Records Guide: Manage Cloudflare and Route 53 as Code nearby.

A minimal launch sequence

If you want the shortest reliable path, the sequence below works for most static website deployment guide scenarios:

1. Build the site locally and verify the output folder.
2. Create the project on your static hosting platform.
3. Deploy the site by upload or Git connection.
4. Add the custom domain in the hosting dashboard.
5. Create the required DNS records at your DNS provider.
6. Wait for DNS resolution and certificate issuance.
7. Test both the root and www hostnames.
8. Enable or confirm redirects so one hostname becomes canonical.

That is the core process whether you use a platform-oriented workflow or a storage-and-CDN workflow.

Checklist by scenario

Use the scenario that matches your setup. The goal is not to memorize every provider’s interface, but to follow the same deployment logic each time you need to deploy a static site with custom domain support.

Scenario 1: Git-based static hosting platform

This is the most common path for developers using static frameworks, Jamstack tooling, or documentation sites. Platforms in this category usually watch your repository, run a build command, publish output, and support automatic HTTPS static site setup through their dashboard.

Checklist

• Confirm your repository builds cleanly on a fresh install.
• Identify the exact build command, such as npm run build.
• Identify the output directory, such as dist or build.
• Create the site or project in your chosen hosting platform.
• Connect the repository branch you want to deploy from.
• Set any required environment variables before the first production build.
• Run the initial deployment and verify the platform-provided preview URL works.
• Add your custom domain in the hosting platform.
• Create the DNS records exactly as requested by the platform.
• Wait for validation and automatic certificate provisioning.
• Test HTTPS on both example.com and www.example.com.
• Configure redirects so only one version is canonical.

Best fit for: marketing sites, docs portals, blogs, portfolios, and frontend apps with no long-running backend process.

Where people get stuck: they point DNS before confirming the build works, or they forget to add environment variables that were present locally.

Scenario 2: Object storage plus CDN

This route is common when you want more control over infrastructure, caching, or cloud account structure. The basic model is: upload static files to a bucket or storage service, put a CDN in front of it, then connect the custom domain and certificate.

Checklist

• Build the static site and verify links, asset paths, and relative URL behavior.
• Create a storage bucket or equivalent destination for site files.
• Upload the build output with the correct folder structure intact.
• Enable static website hosting if your platform requires it.
• Create or configure a CDN or edge distribution in front of the bucket.
• Attach your custom domain to the distribution.
• Request or enable a certificate for the exact hostnames you plan to serve.
• Create the DNS record that points the domain to the CDN endpoint.
• Invalidate cache or confirm new objects are visible after deployment.
• Test deep links, not just the homepage.
• Confirm index and error document behavior if your site is a single-page app.

Best fit for: teams that want infrastructure control, cloud-native workflows, or tighter integration with existing accounts.

Where people get stuck: bucket website endpoints and CDN endpoints are not interchangeable, and certificates often need to match the exact serving layer you expose publicly.

Scenario 3: Static site on a VPS behind Nginx

This is not the lightest option, but it can be practical if you already run a server and want to serve static output yourself. In this setup, your server hosts the files and Nginx handles requests, redirects, and TLS termination.

Checklist

• Provision and secure the server before deployment.
• Copy the static build output to the target directory on the server.
• Create an Nginx server block for your domain.
• Set the document root to the static output directory.
• Test the Nginx configuration before reload.
• Open ports 80 and 443 in the firewall.
• Point your domain’s DNS records to the server IP.
• Issue an SSL certificate with your preferred automation method.
• Enable HTTP-to-HTTPS redirection.
• Reload Nginx and test with curl and a browser.
• Set up a basic deployment script or CI job so future updates are repeatable.

Best fit for: self-hosted environments, internal sites, or teams that already maintain Linux infrastructure.

For this path, useful follow-up reads are Linux Server Setup Checklist for New App Deployments and Nginx Reverse Proxy Setup Guide for Node.js, Docker, and SSL.

Scenario 4: CI/CD-driven deployment for static hosting

If your goal is repeatability, use your CI pipeline to build and deploy rather than relying on local manual steps. This is often the most reliable way to connect domain to static hosting once the first deployment is complete.

Checklist

• Store build settings in version control.
• Use a lockfile so installs are predictable.
• Create a CI workflow that installs dependencies, runs tests if needed, and builds the site.
• Deploy artifacts to your hosting target from the main branch or release tags.
• Store API tokens and secrets in your CI provider’s secret manager.
• Fail the deployment if the build output folder is missing or empty.
• Publish a preview environment for pull requests if your platform supports it.
• Reserve production deploys for reviewed merges.
• Document rollback steps, even for a static site.

Best fit for: teams, multi-maintainer sites, and projects with regular content or release changes.

If your broader deployment flow becomes more complex, keep Deployment Troubleshooting Checklist: What to Check When a Release Fails on hand.

What to double-check

These are the details that deserve a second pass before you call the deployment done. Most launch issues are caused by a small mismatch here, not a major platform problem.

1. Canonical hostname

Choose whether example.com or www.example.com is primary. Then make sure:

• both hostnames resolve, if you want both accessible;
• one redirects to the other consistently;
• your certificate covers both names if both are exposed during redirects;
• your app, CDN, or hosting settings match this decision.

Do not treat root and www as an afterthought. It is one of the most common reasons a site appears half-configured.

2. DNS record type

Use the record type your platform expects. In many cases:

• A or AAAA records point a hostname to an IP address.
• CNAME records point a hostname to another hostname.

A frequent mistake is trying to set a CNAME at the root on providers that do not support it in the expected way, or mixing an old A record with a new CNAME for the same name. If you are unsure, review How to Use Dig, Nslookup, and Whois to Troubleshoot Domain Problems.

3. DNS authority

Make sure you are editing the live zone. Many failed launches come from changing records at the registrar while the nameservers actually point to another DNS provider. Before you troubleshoot propagation, verify where the domain is authoritative.

4. TTL expectations

DNS changes are not always instant. Lower TTL values can help before planned migrations, but TTL changes made at the last minute may not fully benefit users who already cached earlier values. In practice, plan DNS changes ahead of time rather than assuming instant propagation.

5. Certificate coverage

Automatic HTTPS is convenient, but it still depends on the platform being able to validate your domain correctly. Double-check:

• the domain is added in the hosting platform;
• DNS points where the platform expects;
• you are not using stale or conflicting records;
• both root and www are included if needed.

If HTTPS fails after a DNS change, see How to Fix ERR_SSL_PROTOCOL_ERROR After DNS or Hosting Changes.

6. Asset and route paths

A site that loads the homepage but breaks on stylesheets, JavaScript, or nested URLs often has a path issue rather than a DNS issue. Check:

• your static site generator base URL setting;
• whether assets are referenced with absolute or relative paths;
• single-page app fallback routing behavior;
• trailing slash assumptions.

7. Redirect behavior

Test all four common entry points:

• http://example.com
• https://example.com
• http://www.example.com
• https://www.example.com

They should all end up on the single canonical HTTPS URL you chose.

Common mistakes

If your static site HTTPS setup is not working, these are the first mistakes to rule out.

Pointing DNS before confirming the site works

Always verify the site on the platform’s temporary or preview URL first. If the build itself is broken, switching the domain only makes diagnosis harder.

Leaving old records in place

Conflicting A, AAAA, or CNAME records can send different clients to different places. Remove obsolete records instead of layering new ones on top and hoping the right one wins.

Forgetting the apex domain

Some teams configure only www and forget the root domain, or the reverse. Decide whether you want both reachable, then configure both intentionally.

Assuming HTTPS is immediate

Automatic certificate issuance may take some time after DNS is correct. It is reasonable to wait, but if it stays pending longer than expected, inspect DNS carefully rather than repeatedly redeploying.

Testing from one browser only

Your local cache can hide changes. Test with:

• a private browsing window;
• dig or nslookup from the terminal;
• curl -I to inspect redirects and headers;
• a second network, if needed.

If the domain does not resolve at all, How to Fix DNS_PROBE_FINISHED_NXDOMAIN for Websites, APIs, and Local Development is the right troubleshooting path.

Not documenting the final working setup

Once the deployment works, record:

• the hosting platform and project name;
• the canonical domain;
• the required DNS records;
• the redirect rules;
• the CI workflow or deployment command;
• who owns DNS access and hosting access.

This turns a one-off launch into a repeatable deployment guide for your team.

When to revisit

This checklist is worth revisiting any time the underlying workflow changes. Static hosting is stable, but your domain, provider, and build process often evolve around it.

Review the deployment when any of the following happens:

• You switch DNS providers or update nameservers.
• You move from manual deploys to CI/CD.
• You change the canonical domain from root to www or back.
• You migrate to a different static hosting platform.
• You add preview environments, staging domains, or branch deploys.
• You change your static site generator or output path.
• You add a CDN, proxy layer, or custom edge logic.
• You notice certificate renewals or redirect behavior becoming unreliable.

A practical maintenance routine looks like this:

1. Before a planned launch or seasonal update: confirm the build command, output folder, domain settings, and DNS records are still current.
2. After any infrastructure change: test root, www, HTTPS, redirects, and a deep link.
3. Quarterly or when ownership changes: review who controls the registrar, DNS provider, hosting account, and CI secrets.
4. After an incident: update your checklist with the exact cause so the same problem is easier to catch next time.

If you want a simple action list to keep nearby, use this final pre-launch checklist:

• Build succeeds in a clean environment.
• Output folder is correct.
• Site works on the provider preview URL.
• Custom domain is added in hosting settings.
• DNS records match the provider instructions exactly.
• Old conflicting records are removed.
• Root and www behavior is intentional.
• HTTPS is issued and valid.
• HTTP redirects to HTTPS.
• Deep links, assets, and error pages work.
• Deployment steps are documented for the next release.

That process is usually enough to connect domain to static hosting cleanly and keep it maintainable. When your setup grows beyond a simple static site, move to more opinionated infrastructure guides such as How to Deploy a Node.js App on a VPS With Nginx, PM2, and SSL. But for static sites, the winning approach is still the same: keep the path from build output to DNS to HTTPS as simple and explicit as possible.