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.
For a supported Ghost production site in 2026, use Ubuntu 24, Node.js 22 LTS, MySQL 8.0, NGINX and Systemd on a server with at least 1 GB of RAM. Run Ghost commands as a non-root user, configure a public HTTPS URL, and plan for more memory if the same VPS also runs MySQL, mail, security tools and the operating system. A 2 GB, 1-vCPU VPS is a sensible starting point for a small publication, while 1 GB is the documented minimum rather than a guarantee of comfortable operation.
Official production stack
Ghost’s supported self-hosting architecture is deliberately specific. The current production stack consists of:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Ubuntu 24
- Node.js 22 LTS
- MySQL 8.0
- NGINX as the public web server and reverse proxy
- Systemd to keep Ghost running as a service
- A dedicated non-root Linux user for Ghost commands
- At least 1 GB of server memory
Ghost 6.0 restates this combination as “Ubuntu 24, Node 22, and MySQL8.” Other operating systems, databases and web servers may work, but Ghost does not identify them as officially supported or widely adopted production choices. Using the documented stack gives you the clearest upgrade path and the configuration expected by Ghost’s installation tooling.
What the minimum means
“At least 1 GB memory” is the upstream floor. It is not a promise that every publication will run comfortably at that size. RAM is shared by Ghost, Node.js, MySQL, NGINX, Systemd, logging, security software and Ubuntu itself. A site with more traffic, members, integrations or background jobs can need additional headroom.
What Ghost does not specify
Ghost’s official requirement does not publish a universal CPU model, storage quota, bandwidth allowance or monthly visitor limit. Those values depend on the theme, image sizes, integrations, publishing workflow, traffic pattern and caching. Do not treat a generic “recommended” disk or bandwidth number as a Ghost requirement.
How much RAM and CPU should a VPS have?
Documented minimum: 1 GB RAM
A 1 GB server can satisfy the stated minimum for the supported stack, especially for a lightly used installation with carefully limited services. Because the operating system and database also need memory, leave room for bursts such as installation, migrations, image processing and backups. A system that constantly swaps to disk will feel slow even when Ghost technically starts.
Practical starting point: 2 GB RAM and 1 vCPU
DigitalOcean’s official Ghost marketplace image is built and tested on a 2 GB, 1-vCPU droplet. That image places Ghost alongside MySQL, NGINX, Postfix, fail2ban, UFW and the operating system, so its size is a useful practical baseline for a small production publication. It is not a universal Ghost requirement or a guarantee for every workload; it is a tested starting configuration for a particular packaged setup.
| Resource | Official minimum or documented figure | How to interpret it |
|---|---|---|
| Memory | At least 1 GB | Ghost Foundation’s production floor; workload headroom is not guaranteed. |
| Memory for a small all-in-one VPS | 2 GB | DigitalOcean’s 2 GB, 1-vCPU marketplace image includes Ghost and common system services. |
| CPU | Not stated as a universal requirement | 1 vCPU is the tested marketplace-image size, not a rule for all sites. |
| Storage | Not stated | Choose capacity based on media, backups, logs and operating-system space. |
| Bandwidth or traffic | Not stated | Use caching and a CDN as traffic grows instead of assuming a fixed limit. |
When to move beyond the baseline
Increase memory or separate services when MySQL uses most available RAM, the kernel begins swapping, deployments fail for lack of memory, or response times deteriorate during backups and imports. High-traffic publications should add a CDN and caching layer in front of Ghost. Ghost’s guidance notes that a solid cache can serve very large request volumes, while the application itself does not support clustering or sharding.
Production prerequisites before installation
Public URL and DNS
Decide the publication’s public domain before running a production installation. Ghost stores this URL in its configuration, and the value should include https:// when SSL is enabled. Point the domain’s DNS records to the VPS and ensure inbound web traffic can reach the server.
Database
MySQL 8.0 is the default production database in Ghost’s supported stack. A production publication needs a database and a database user with the permissions required by Ghost. Keep database credentials out of shell history and public repositories.
Free tools Windows power users keep installed
One-click scans. No signup required.
Reverse proxy and service manager
NGINX normally listens on public ports 80 and 443, terminates HTTPS, and proxies requests to Ghost’s local Node process. Systemd starts Ghost at boot and restarts it when configured to do so. Ghost commands should be run from a dedicated non-root account; use root only for operating-system administration that requires it.
HTTPS is a requirement for safe administration
Ghost recommends SSL for every production publication. Without HTTPS, usernames and passwords can be sent in plaintext between the browser and server. Use a valid certificate, redirect HTTP to HTTPS, and verify that the configured Ghost URL and certificate use the same hostname.
Installing Ghost with Ghost-CLI
Ghost-CLI’s production workflow is designed to configure the supported components rather than leave you with a manually assembled Node process. The exact prompts can change between CLI releases, but the production sequence normally covers these tasks:
- Prepare Ubuntu 24. Update the operating system, create a dedicated non-root user, and make sure DNS already points the intended hostname at the server.
- Install the supported Node.js and MySQL versions. Use Node.js 22 LTS and MySQL 8.0 for the current official stack. Confirm the versions before creating the publication.
- Create the Ghost installation directory. Give the non-root Ghost user ownership of the directory so the CLI does not need to run as root.
- Run the production installer. Ghost-CLI can create and configure the MySQL database and user, write the Ghost configuration, generate an NGINX site, and create the Systemd service.
- Set the publication URL. Enter the complete HTTPS URL, including the correct hostname. A mismatch between DNS, the Ghost URL and the certificate is a common cause of redirect and login problems.
- Enable SSL. Ghost-CLI can request a free Let’s Encrypt certificate through its SSL setup flow. Allow HTTP and HTTPS traffic so certificate validation and normal browser access work.
- Complete the administrator setup. Open the HTTPS site, create the owner account and confirm that the admin panel, front end and email configuration behave as expected.
- Test restart and updates. Reboot or restart the Systemd service and verify that Ghost returns automatically. Apply updates in a maintenance window and check logs after each change.
This path is different from a local development install. ghost install local is intended for development, uses SQLite and runs with a local process manager. It should not be presented as the production architecture for a public publication.
Firewall and hardening checklist
A working installation is only the beginning of operating a public server. Apply the following controls before publishing sensitive content or collecting member data:
- Use HTTPS and renew the certificate before it expires.
- Consider a separate admin domain where that separation fits your threat model and operating process.
- Run
mysql_secure_installationto remove unsafe default MySQL settings. - Configure UFW to permit only the ports you need: SSH for administration, NGINX, HTTP and HTTPS.
- Disable SSH password authentication after key-based access is confirmed.
- Disable direct SSH root login.
- Keep Ubuntu, Node.js, MySQL, NGINX, Ghost and security tooling up to date.
- Store backups off the VPS and periodically test restoring both the database and uploaded content.
- Monitor disk space, memory, service status, certificate expiry and error logs.
Restricting SSH does not replace application security. Use strong administrator credentials, least-privilege database access and a recovery method that does not depend on a single laptop or browser session.
Can Ghost run on a VPS?
Yes. A VPS is the normal self-hosting model: you rent a virtual Linux server, install the supported stack, point DNS at it and operate the software yourself. The VPS must provide enough memory for Ubuntu, Ghost, MySQL, NGINX and your security and mail services. Start with the documented 1 GB floor only when you understand the resulting constraints; 2 GB is a more forgiving baseline for a small all-in-one production server.
VPS selection should therefore be based on operational features as well as raw specifications. Look for reliable snapshots or backup exports, console access for recovery, a static public IP, clear firewall controls and a region close to your audience. Ghost does not publish a mandatory provider, CPU family or storage size, so those are infrastructure decisions rather than Ghost compatibility requirements.
Can Ghost be self-hosted with Docker?
Core Ghost production versus new services
Ghost’s official production guidance centers on Ubuntu, Node, MySQL, NGINX and Systemd. Ghost 6 introduces newer Social Web (ActivityPub) and Web Analytics services as separate services. For those services, Docker Compose is currently a preview self-hosting path, not a replacement statement that every Ghost production installation must use Docker.
Rank #4
What the roadmap means
Ghost says Docker Compose is planned to become the default installation approach from Ghost 7.0. That is a future direction, not a current requirement for Ghost 6 production sites. If you choose the preview path, treat it as an operationally different deployment: you must manage Compose files, images, persistent volumes, networking, upgrades and backups in addition to the Ghost publication.
ActivityPub limits to account for
Ghost’s current hosting documentation lists limits for the hosted ActivityPub service used by self-hosters: a maximum of 2,000 followers, 2,000 accounts followed and 100 interactions per day. These are service limits, not RAM requirements for the core Ghost editor and publishing stack.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Scaling a self-hosted publication
Cache before adding complexity
Put a CDN and caching layer in front of the VPS as readership grows. Cacheable pages and assets can be served without waking the Ghost process for every request, reducing pressure on Node.js and MySQL. Review cache invalidation for newly published posts, member-only content and personalized responses.
Know the architecture boundary
Ghost does not support clustering or database sharding. Do not design a multi-node Ghost cluster expecting official support. Instead, keep the primary instance reliable, move static delivery and cacheable traffic to the edge, and improve observability and recovery procedures.
Measure before resizing
Track memory pressure, swap activity, MySQL slow queries, request latency, error rates, disk growth and backup duration. Resize when measurements show sustained contention, not merely because a provider offers a larger plan. A cache hit-rate improvement can solve a traffic problem that a larger database server would not.
Best Value
Self-hosting versus managed Ghost hosting
Ghost(Pro) is the official managed-hosting option. The choice is less about whether Ghost can run and more about who operates the underlying system.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems| Decision area | Self-hosted Ghost | Ghost(Pro) |
|---|---|---|
| Operational responsibility | You handle patching, backups, security, monitoring, sizing and incident response. | Ghost manages weekly updates, backups, security and performance. |
| Infrastructure control | Maximum control over the VPS, network, database and deployment process. | Less infrastructure control in exchange for a managed service. |
| Resource planning | You choose RAM, CPU, storage, region and scaling strategy. | Server sizing is abstracted from you. |
| Advanced services | ActivityPub and Web Analytics currently use the Docker Compose preview path when self-hosted. | Hosted services have their own documented usage limits and operating model. |
| Best fit | Teams that need infrastructure control and can operate Linux services. | People who prefer publishing without managing servers. |
Choose self-hosting when you can maintain a patching schedule, test backups, secure SSH, monitor the service and respond to outages. Choose managed hosting when those responsibilities would distract from publishing or exceed your team’s operations capacity. No universal price comparison is stated here; evaluate the provider’s current plan and usage terms separately.
Common failure modes and fixes
Ghost starts but the site is unreachable
Check DNS resolution, the VPS firewall, UFW rules and whether NGINX is listening on ports 80 and 443. Then inspect the Systemd and NGINX logs. A local Ghost process can be healthy while the reverse proxy or DNS is wrong.
Redirect loops or certificate errors
Confirm that the configured Ghost URL uses https://, the certificate covers the exact hostname and NGINX forwards requests consistently. Remove conflicting manual redirects before re-running the SSL setup.
Installation fails during database setup
Verify that MySQL 8.0 is running, the database user has the required permissions, the hostname and port are correct, and the server has enough free memory for the initial schema and migration work. Do not run the Ghost CLI as root to bypass ownership errors; correct directory ownership instead.
Memory exhaustion after adding services
Inspect RAM and swap usage while Ghost, MySQL, mail, fail2ban and backup jobs are active. Reduce unnecessary services or move them to another host, then resize the VPS if pressure continues. The 1 GB figure is a floor, not a capacity promise.
Local development was mistaken for production
If the installation uses SQLite and a local process manager because it was created with ghost install local, rebuild or migrate to the production stack before opening the site to the public. Production requires MySQL, NGINX, Systemd, HTTPS and a properly configured public URL.
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.
