Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
To run Ghost at blog.example.com, point that subdomain to your Ghost deployment, install or configure Ghost with the complete HTTPS address as its production URL, and place it behind a correctly configured web proxy with TLS. On a self-managed server, Ghost-CLI can configure the production stack, including MySQL, NGINX, systemd, and SSL. With Ghost(Pro), you attach the custom domain in the managed service and its certificate is issued automatically.
The detail that causes most failures is the URL and proxy protocol: Ghost must see the same canonical HTTPS hostname that readers use, and a reverse proxy must forward X-Forwarded-Proto: https. If it reports HTTP instead, Ghost can redirect to HTTPS repeatedly and create an infinite loop.
What running Ghost on a subdomain involves
A subdomain is a separate hostname under your main domain. In this example, example.com is the parent domain and blog.example.com is the Ghost publication. The setup has four independent layers:
- DNS: tells browsers where
blog.example.comshould connect. - Ghost: stores the publication URL and generates links, feeds, asset paths, and admin redirects from it.
- Web proxy: normally NGINX (or a provider-managed equivalent) receives public web traffic and passes it to Ghost.
- TLS: encrypts HTTPS traffic and must cover the exact subdomain.
All four must agree. A DNS record aimed at the wrong server, a Ghost URL that still uses the parent domain, or a proxy that loses the original HTTPS protocol can make the site appear partially broken even when the Ghost process itself is running.
#1 Best Overall
Choose self-hosting or Ghost(Pro)
Decide who will operate the server before changing DNS. Ghost’s documentation treats self-hosting and Ghost(Pro) as different deployment models, not two installation screens for the same service.
| Decision area | Self-hosted Ghost with Ghost-CLI | Ghost(Pro) |
|---|---|---|
| Server maintenance | You maintain the server, operating system, backups, firewall, monitoring, and capacity. | The hosting service operates the application environment and underlying infrastructure. |
| NGINX and TLS control | You can inspect and change NGINX and certificate behavior. Ghost-CLI can configure NGINX and SSL during a production install. | The provider controls the proxy and certificate workflow; you configure the custom domain through its service. |
| Upgrades | You schedule and perform Ghost and system upgrades, then verify the site. | The managed service handles the platform side of upgrades according to its service process. |
| DNS and proxy work | You create the subdomain record and ensure your server proxy preserves the host and HTTPS protocol. | You create the required DNS record and follow the provider’s domain-verification instructions. |
| Recurring hosting cost | Depends on the server, storage, backups, and operational services you select; no single current price applies. | Depends on the Ghost(Pro) plan and billing term; the official deployment guidance does not establish a comparable universal price. |
| Best fit | Operators who need server-level control and can administer Linux, DNS, NGINX, and TLS. | Publishers who prefer managed operations over server administration. |
If you need to edit NGINX rules, select your own certificate provider, or run other services on the same machine, self-hosting provides that control. If keeping a server patched and recoverable is not part of your routine, a managed deployment removes that operational burden.
Plan the hostname and DNS record
Pick one canonical hostname
Choose the public address before installation, such as https://blog.example.com. Use one spelling and one scheme everywhere. Do not alternate between blog.example.com, www.blog.example.com, an IP address, and a temporary provider hostname. Ghost’s configured URL is the basis for generated links and redirects.
Create the subdomain record
At the DNS provider for example.com, create a record for the host label blog. The value depends on your deployment:
- For a self-hosted server, point the record to the server’s public address.
- For Ghost(Pro), point the record to the target supplied in the Ghost(Pro) domain setup flow.
DNS changes can take time to appear at different resolvers. Do not issue a certificate for a hostname that still resolves to an old server. Confirm that the record resolves to the intended deployment before troubleshooting Ghost itself.
Self-hosted installation with Ghost-CLI
Ghost-CLI is Ghost’s supported command-line installation and configuration tool. Its production workflow is designed to configure the application, MySQL, NGINX, systemd, and SSL rather than leaving you to assemble each component manually.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
1. Prepare the server
Use a server that you can administer and that meets Ghost’s currently supported operating-system and runtime requirements. Create or select the account that will own the Ghost installation, ensure it can use the required administrative privileges when the installer asks, and decide where the publication files and database will live.
Before installation, have these values ready:
- The complete canonical URL:
https://blog.example.com. - The DNS record already aimed at this server.
- Database credentials or permission to let Ghost-CLI create the production database configuration.
- An email address for administrative and certificate-related prompts.
- A backup destination separate from the server.
Do not begin with an IP address and plan to “change it later.” Ghost can be reconfigured, but links, cookies, certificates, and proxy rules are easier to get right when the final hostname is used from the first production install.
2. Run Ghost-CLI’s production install flow
From the directory where the publication should be installed, start Ghost-CLI’s production installation process. When it asks for the site URL, enter the full HTTPS subdomain, including the scheme and hostname:
https://blog.example.comAllow the installer to configure the production services it supports. A successful run should leave Ghost managed as a service, with a database connection, an NGINX site definition, and the production URL recorded in Ghost’s configuration.
If the installer detects that the hostname does not resolve correctly, stop and fix DNS first. Continuing with an unresolvable name commonly leads to failed certificate issuance or a proxy that answers for the wrong site.
3. Complete the administrator setup
Open the public subdomain over HTTPS and then visit the Ghost admin path at /ghost/. Create the administrator account and confirm that the admin interface, publication title, timezone, and staff settings are correct. The admin path is a useful early test because it exercises both the public proxy and Ghost’s authenticated routes.
Configure NGINX or another reverse proxy correctly
In a typical production deployment, browsers connect to NGINX over HTTPS and NGINX forwards the request to Ghost. Ghost does not need to be directly exposed to the internet when the proxy is working correctly.
Preserve the host
The proxy must pass the requested hostname so Ghost knows that the request was for blog.example.com. If the proxy substitutes an internal hostname, Ghost may generate links to that internal name or reject host-dependent behavior.
Recommended Free Tools
Forward the original protocol
When TLS terminates at NGINX, a load balancer, or another edge proxy, pass:
X-Forwarded-Proto: httpsGhost’s reverse-proxy guidance specifically warns that an incorrect forwarded-protocol value makes Ghost believe the request is insecure. Ghost then redirects to an HTTPS URL while the proxy keeps presenting the request as HTTP, producing an infinite redirect loop.
Forward the client context
Preserve the original host and client connection information using the proxy’s standard forwarding headers. The exact directive names vary by proxy, but the result should be consistent: Ghost receives the public host, knows that the browser used HTTPS, and can construct secure absolute URLs.
Redirect HTTP to HTTPS
Expose an HTTP listener only to redirect the same hostname to HTTPS. Do not serve a separate copy of the publication over plain HTTP. Ghost’s production guidance recommends SSL, and Ghost(Pro)’s reverse-proxy rules require HTTPS behavior and an HTTP-to-HTTPS redirect.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Enable and verify TLS
Self-hosted certificate
If Ghost-CLI is managing the production install, follow its SSL setup prompts and make sure certificate issuance is requested for blog.example.com, not for the parent domain alone. Certificate validation will fail if DNS still points elsewhere, if the proxy blocks the validation request, or if an existing web server is answering for the hostname.
Managed certificate on Ghost(Pro)
Ghost(Pro) custom domains receive an SSL certificate automatically after the domain is connected and the required DNS configuration is in place. Wait for the provider to report that the domain is active before assuming a browser certificate warning indicates a Ghost application problem.
Best Value
Check the complete HTTPS path
Test from a normal browser session and, if possible, a second network:
- Open
https://blog.example.comand confirm the home page loads without a certificate warning. - Open
http://blog.example.comand confirm it redirects to the HTTPS address. - Open
https://blog.example.com/ghost/and confirm the admin screen appears. - Load a post containing images, scripts, and stylesheets. Every asset should use the same HTTPS hostname.
- Upload an image in the editor and open the published post to verify that the stored image URL is reachable.
Set Ghost’s production URL and canonical behavior
Ghost’s production URL must be the complete HTTPS address, not merely the domain name and not an internal service address. This setting controls canonical links, feeds, image references, admin redirects, and links generated in emails.
If more than one hostname reaches the server, select one canonical address and redirect the others to it. For example, if both a temporary provider hostname and blog.example.com work, keep only the latter as the public URL and redirect the temporary name. Apply the same decision to any www variant. Multiple live copies create inconsistent cookies, duplicate URLs, and confusing certificate behavior.
Use Ghost(Pro) with a subdomain
1. Add the custom domain in Ghost(Pro)
In the Ghost(Pro) administration area, open the publication’s domain or site-address settings and enter the complete subdomain you want readers to use. The service will show the DNS target and any verification state associated with that hostname.
2. Publish the DNS record
At your DNS provider, create the record exactly as Ghost(Pro) specifies. A record aimed at a self-hosted server, an old provider, or an unrelated parking page will prevent verification and certificate issuance.
3. Wait for activation, then test
After DNS resolves to the Ghost(Pro) target, wait for the managed service to verify the domain and provision SSL. Test the HTTPS home page, /ghost/, asset loading, image uploads, and the HTTP-to-HTTPS redirect. If the provider offers reverse-proxy settings, follow its required host and forwarding-header rules exactly; HTTPS is mandatory in those rules.
Troubleshooting by symptom
| Symptom | Likely cause | What to check |
|---|---|---|
| DNS resolves to the wrong machine | The subdomain record still points to an old address or target. | Check the record at the authoritative DNS provider and compare the result with the server or Ghost(Pro) target. |
| Certificate cannot be issued | DNS is not live, the hostname is misspelled, or another proxy answers the validation request. | Confirm the exact hostname, wait for DNS propagation, and ensure the intended proxy serves that host. |
| Browser shows “too many redirects” | The proxy is not telling Ghost that the original request used HTTPS. | Verify X-Forwarded-Proto: https, the HTTPS listener, and the HTTP-to-HTTPS redirect. |
| Ghost redirects to an IP or temporary hostname | The production URL still contains the installation address. | Change Ghost’s URL to the full canonical HTTPS subdomain and restart or reload the affected service. |
| Home page works but images or scripts fail | Generated asset URLs use a different hostname or HTTP scheme. | Inspect the failing URL, then correct the Ghost URL and proxy protocol/host forwarding. |
/ghost/ is unavailable while the home page works |
A proxy rule, path restriction, or service error affects the admin route. | Check the NGINX site configuration, Ghost service status, and proxy error logs for that path. |
| Uploads fail | Ghost cannot write to its content storage, or the proxy limits the request. | Check filesystem ownership and available space on self-hosted systems, then review proxy request-size and timeout settings. |
Operational checks after launch
A subdomain installation is not finished when the first page opens. Add these checks to your maintenance routine:
- Backups: back up both the Ghost database and uploaded content, and periodically test restoring them.
- Certificate renewal: confirm that automatic renewal is active or record the manual renewal procedure used by your proxy.
- DNS ownership: document who controls the zone and where the record points so a later DNS change does not silently detach the publication.
- Service monitoring: monitor the public HTTPS endpoint and the Ghost service separately; a running process can still be hidden behind a broken proxy.
- Upgrade windows: on self-hosted installations, update Ghost and the operating system deliberately, then retest the home page, admin route, assets, and uploads.
- Canonical host: periodically test alternate hostnames and confirm they redirect to the one HTTPS address you publish.
Key decisions before you go live
Use self-hosting when you can own the full chain from DNS through Linux, NGINX, TLS, database, backups, and upgrades. Use Ghost(Pro) when you want Ghost’s team and hosting platform to handle the server side and you are comfortable following its DNS and domain workflow. Whichever model you choose, the non-negotiable configuration is the same: DNS must reach the deployment, Ghost must use the full HTTPS subdomain as its production URL, the proxy must preserve the host and HTTPS protocol, and every alternate hostname must redirect to one canonical address.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
