You can host a website on DigitalOcean three ways: a Droplet (a virtual server you configure with nginx and certbot), App Platform (a managed build-and-deploy service), or Spaces (S3-compatible object storage that can serve a static site behind a CDN).
They are not interchangeable. A Droplet gives you the most control and the most chores. App Platform trades control for convenience. Spaces is only for static files. Here is what each looks like in practice, with the commands for the Droplet route, because the time you spend on it is the real cost, and it is the one the marketing pages leave out.
Table of contents
- The three routes, in one paragraph each
- The Droplet route, step by step
- HTTPS with certbot, and what keeps it alive
- The ops overhead nobody puts on the pricing page
- App Platform and Spaces: less to operate, less to control
- The managed alternative, and how to choose
- How this fits the rest of the stack
- FAQ
The three routes, in one paragraph each
A Droplet is a virtual machine. You choose an image (usually Ubuntu), a size and a region, log in over SSH, and from that point everything is yours: the web server, the firewall, the updates, the process manager, the backups. It suits people who want to learn, need unusual software, or run several small things on one machine.
App Platform is a platform-as-a-service. You connect a Git repository, it detects the framework or a Dockerfile, builds it, deploys it behind HTTPS, and offers scaling and rollbacks. You do not see a server. It suits typical web apps and static sites, and it is the closest DigitalOcean gets to a click-and-deploy host. We cover it in the App Platform post.
Spaces is object storage with an S3-compatible API and an optional CDN. You upload files and, for a static site, serve them from a bucket. It has no build step, no server side code and no redirects by default, so it fits pure HTML sites or asset hosting rather than applications.
The DigitalOcean website hosting page lists all three; the useful question is which one matches how much operating you want to do. The rest of this guide is the same question asked with commands.
The Droplet route, step by step
Create an Ubuntu Droplet, add your SSH key, and log in. The first hour is the same on every server: updates, a non-root user, a firewall, and only then the web server. Our VPS configuration checklist covers the hardening in detail.
sudo apt update && sudo apt upgrade -y
sudo adduser deploy && sudo usermod -aG sudo deploy
sudo ufw allow OpenSSH && sudo ufw allow 'Nginx Full' && sudo ufw enable
sudo apt install -y nginxPoint your domain at the Droplet’s IP with an A record. When DNS resolves, nginx should serve its default page on port 80. Then create a server block for your site and put your files where it says.
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginxThat gets you a static site over plain HTTP. For a dynamic app, replace the try_files block with a proxy_pass to your app server (Node, Gunicorn, PHP-FPM) and run that app under systemd so it restarts after a crash or reboot.
HTTPS with certbot, and what keeps it alive
Certbot is the standard route to a free Let’s Encrypt certificate on a Droplet. It edits the nginx configuration, requests a certificate, and installs a timer that renews it before expiry.
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
sudo systemctl list-timers | grep certbot
sudo certbot renew --dry-runThe dry run matters. Renewal fails silently when a firewall rule blocks port 80, when DNS changes, or when a config edit breaks the challenge path. A certificate that expired at three in the morning is a common way to discover that nobody was watching the timer. Add an external uptime check that also alerts on certificate expiry.
Add the rest: redirect HTTP to HTTPS, set security headers, gzip or brotli, sensible cache headers for static assets, and log rotation. Each is a few lines, and each is a thing you now own. When your traffic changes shape, so does the tuning. A guide to when nginx returns errors you have not seen before is in our 504 gateway timeout post.
None of it is hard. The cost is that it is all yours, forever, on every server you run.
The ops overhead nobody puts on the pricing page
A Droplet’s monthly price covers the machine. It does not cover the work, and the work is recurring. Security updates arrive weekly. Kernel updates need reboots. Disks fill with logs. Backups need configuring and testing. Certificates need watching. An SSH key gets lost when someone leaves. Someone has to be awake when the server misbehaves.
You can automate a lot of it: unattended upgrades, snapshots on a schedule, fail2ban, logrotate, a monitoring agent. But automation has to be set up, tested and maintained, and it fails at unhelpful times. For a hobby site, that is an afternoon and an occasional evening. For a business site, it is a job.
The comparison that matters is not the Droplet price against another host’s price. It is your hourly rate times the hours per month spent on server care, plus the cost of an outage on a night you were not watching. Sometimes running the server is worth it, because you want the control, or you are learning, or you run enough services that the overhead is amortised.
- Weekly: apply security updates, review disk and memory.
- Monthly: test a backup restore, review firewall rules and users.
- Every renewal cycle: confirm certbot renewed and the timer still runs.
- On every incident: SSH in, read logs, decide between restart and rollback.
If most of that list makes you tired rather than curious, the managed route is the honest answer.
App Platform and Spaces: less to operate, less to control
App Platform removes the server. You point it at a repository, choose a plan, and it builds and deploys on every push, with HTTPS handled for you. Static sites can be deployed for free within limits, while dynamic services run on paid tiers. The trade-off is flexibility: you get the buildpacks and instance types it offers, and you cannot install arbitrary system packages.
Spaces suits a purely static site, or the asset layer for a bigger one. You build locally or in CI, sync the output to a bucket, and enable the CDN. Redirects, custom headers and SPA fallbacks need workarounds or a front layer, and there is no server code at all.
# sync a built static site to a Spaces bucket (s3cmd or aws cli configured with your Spaces keys)
aws s3 sync ./dist s3://my-site-bucket --endpoint-url https://nyc3.digitaloceanspaces.com --acl public-readFor a comparison of the managed options inside the same provider, see DigitalOcean managed hosting. Both fit if you accept the platform’s conventions; neither replaces a server if you need a process the platform does not model.
The managed alternative, and how to choose
Choose a Droplet when you want to learn Linux, need software the platforms do not support, or are running many small services where the per-server overhead spreads out. Choose App Platform when you have a standard web app and want deploys from Git. Choose Spaces when the site is only static files and you are comfortable without server logic.
The other option is a managed platform outside DigitalOcean. On RunxBuild, a static site builds from a repository with custom domains, headers, redirects, rewrites and SPA fallback, and 120GB of bandwidth is included before overage; a web service runs Node, Next.js, Python, Go, Ruby, Java, .NET or Docker from GitHub with build logs, a live route, runtime logs and rollback; and managed MySQL or Postgres sits beside it. The static site docs and services docs describe each.
Whichever you choose, keep the code in Git and the infrastructure reproducible. A site you can redeploy from a repository in ten minutes is portable, whatever runs it today.
How this fits the rest of the stack
A Droplet is a fine place to learn and a fair place to run things you enjoy operating; it is a poor place to run something you would rather forget about. If you want the deploy without the server care, the RunxBuild hosting calculator shows what a web service, a database and static hosting cost together. Then connect a repository in the RunxBuild dashboard, get a live route with build and runtime logs, and add your domain. Reference: Static sites on RunxBuild. Whichever route you take, do one thing first: put the site in a Git repository with a build command written down. That single habit makes a Droplet rebuildable, makes App Platform trivial, and makes moving to another host an afternoon of work rather than a weekend of archaeology.
Useful related references:
FAQ
Can I host a website on a DigitalOcean Droplet?
Yes. Create a Ubuntu Droplet, install nginx, point your domain’s A record at its IP, add your files and get a free certificate with certbot. You are responsible for updates, firewall rules, backups and monitoring, so treat the Droplet as a server you operate, not a hosting plan.
What is the easiest way to host a static site on DigitalOcean?
App Platform is the easiest: connect a Git repository, set the build command and output folder, and it deploys with HTTPS. Spaces plus its CDN also works for plain HTML, but it has no build step, and redirects, headers and SPA fallbacks require extra setup.
Does DigitalOcean provide free SSL?
App Platform provisions certificates for custom domains automatically. On a Droplet, you obtain a free Let’s Encrypt certificate yourself with certbot and rely on its renewal timer. Spaces with the CDN can also serve a custom domain over HTTPS using a managed or uploaded certificate.
Is a Droplet or App Platform better for a WordPress site?
Neither is designed as WordPress hosting. A Droplet can run WordPress if you install PHP, MySQL and nginx yourself and maintain them. App Platform does not suit stateful PHP sites with uploads well. A managed WordPress plan removes the maintenance and provides file and database tools.
How much maintenance does a Droplet need?
Expect regular security updates, occasional reboots, log and disk checks, tested backups, certificate renewal monitoring and firewall reviews. Much can be automated, but the automation itself needs to be set up and watched. It is small for a hobby site and a real recurring task for a business.