How do you install WordPress on a VPS?
You run WordPress and its database as separate Docker containers, connect them to each other, and put a reverse proxy in front to handle your domain and HTTPS. WordPress needs a database, PHP, and a web server to function, and Docker lets you bundle most of that into containers you can start, back up, and rebuild without touching the rest of the VPS. It is more setup than shared hosting, and it gives you real control in exchange.
I will walk through what that setup looks like, then say plainly where I think shared hosting is actually the better answer, because it often is.
Why use Docker for a WordPress install?
Because it keeps WordPress contained and portable instead of tangled into the server's system software. A Docker container for WordPress bundles PHP and the web server pieces together in a known, repeatable configuration, and a separate container for MySQL or MariaDB handles the database. If something goes wrong, you can rebuild the WordPress container from scratch without losing your actual site data, which typically lives in the database and an attached storage folder.
This also means WordPress can live alongside other things on the same VPS, similar to the pattern in our guide on hosting multiple sites on one server, without WordPress's specific software requirements interfering with anything else running there.
What does a basic WordPress-on-Docker setup look like?
At minimum, you need a WordPress container, a database container, and a way for them to talk to each other, which Docker Compose handles well by defining both in one file along with the connection between them. You will set a database name, username, and password once, matched between the two containers, and WordPress will connect to that database automatically on first run.
From there, visiting your server's address in a browser starts the familiar WordPress setup wizard, the same one shared hosting shows you, just running on infrastructure you built yourself. That first-run experience being identical to shared hosting is honestly one of the more reassuring parts of this whole process.
How do you connect your domain and get HTTPS working?
Point your domain's DNS at your VPS, covered step by step in our guide on connecting a domain to a VPS, and put a reverse proxy like Caddy in front of the WordPress container. Caddy in particular handles HTTPS certificates automatically once your domain is pointing correctly, which removes what used to be one of the more fiddly parts of running your own WordPress install.
Without HTTPS, browsers will flag your site as not secure, so this step is not optional for anything meant to be public.
What should you double-check before your first real post?
Make sure your WordPress files and uploads folder are stored on a persistent Docker volume, not just left inside the container itself. Containers are meant to be disposable, rebuilt or replaced without much thought, and anything stored only inside one disappears the moment that happens. A persistent volume keeps your uploaded images, themes, and plugin files intact across rebuilds, which matters the first time you need to update the container image.
It is also worth testing that your database credentials and connection settings actually survive a full restart of both containers, not just the WordPress one. The first time I set up a self-hosted app like this, I learned the hard way that a small typo in a connection setting can work fine until the moment something restarts, and then it quietly stops working. A five-minute test now saves a confusing troubleshooting session later.
How do you keep WordPress updated and secure?
Regularly, and this is the part shared hosting often does for you that a VPS install leaves in your hands. Outdated plugins and themes are the single most common way WordPress sites get compromised, so update WordPress core, themes, and plugins on a schedule rather than waiting for a problem. Keep the underlying server itself updated too, and follow basic server security practices, since a WordPress site is only as secure as the server underneath it.
Back this up properly as well, following the same snapshot plus file backup approach covered in our post on backing up a VPS and testing the restore. A WordPress database with months of posts and comments is exactly the kind of thing you do not want to lose.
What is actually harder about this than shared hosting?
Everything shared hosting does automatically becomes your job: installation, updates, backups, security patching, and troubleshooting when something breaks. None of it is especially difficult in isolation, but it adds up to real ongoing maintenance that a managed plan simply absorbs for you. The tradeoff is control. You can run WordPress alongside other projects, tune the server exactly how you want, and are not limited by a shared hosting plan's rules. Whether that tradeoff is worth it depends entirely on whether you want that control.
When is shared hosting honestly the better choice?
When you want a WordPress site and nothing more, without taking on server maintenance as a hobby you did not ask for. That is a completely reasonable thing to want, and managed shared hosting plans exist specifically for it, installing WordPress, applying updates, and handling much of the security work without you thinking about it. I run my own sites and tools on a VPS because I want that control and do not mind the upkeep, but I would not tell someone who just wants a working WordPress blog to go set up Docker containers for it. If maintaining a server is not something you want to spend time on, shared hosting is the honest recommendation, not a consolation prize. There is no extra credit for doing it the harder way if the easier way gets you exactly what you actually wanted.
Next step: if you decide the VPS route is right for you, our automation hub has more guides on Docker, servers, and getting projects running the way you want them.
