From Zero to Production Backend with HTTPS in One Copy-Paste: Magic Cloud on DigitalOcean

Modern deployment orthodoxy is very clear about what you need to run a backend in production: a Kubernetes cluster, a CI/CD pipeline, a "platform team", an observability stack, and a cloud bill with a comma in it. Preferably also a DevOps engineer to babysit all of the above, because none of it babysits itself.

Here's what you actually need: one $12 droplet, and one copy-paste.

Everything below deploys a complete production backend - API, admin UI, database, and automatic HTTPS - and the only "pipeline" involved is Ctrl+C, Ctrl+V.

The deployment is a text file. The text file is the tutorial.

What you're actually getting

Before the steps, let's be precise about what comes out the other end, because "simple" usually means "toy" and this isn't one.

One droplet, running one Docker container. The container holds the Magic Cloud backend - an ASP.NET Core API on an internal port, never publicly exposed - which also serves its own compiled Angular admin UI. No nginx for the frontend, no separate frontend service, no second container to keep in sync. In front of it sits Caddy, which obtains and renews free Let's Encrypt certificates for your domain automatically. An internal SQLite database is created on first boot, and later you can connect MySQL, PostgreSQL, or SQL Server through the UI.

Your data lives in four named Docker volumes - databases and uploads, config (including your JWT secret), installed modules, and your own files. These survive upgrades, reboots, and container rebuilds. This is the part enterprise vendors charge you a retainer to explain, and here it's just... four volumes.

This walkthrough follows the official DigitalOcean deployment doc in the repository - that's the canonical reference if you want every detail.

Step 1: The copy-paste

Create a droplet. Pick Ubuntu 24.04 and a plan with at least 2 GB RAM - 4 GB is the comfortable choice. Why does a backend this lean want that much memory? It doesn't. The Angular production build during first boot does, because frontend tooling in 2026 remains a gas that expands to fill all available RAM. The deployment script even creates a 4 GB swap file specifically so cheap droplets don't get OOM-killed mid-build. That's the level of "it just works" we're going for: the script assumes the worst and handles it.

Now the actual deployment:

1. Open .do/cloud-init.yaml from the repository
2. Edit one line - DOMAIN= - to the domain you'll be using
3. Copy the entire file, and paste it into Advanced Options / User Data on the droplet creation form
4. Create the droplet
5. Point your domain's DNS A record at the droplet's IP

That's it. That's the deployment. The cloud-init file installs Docker, clones the repository, builds the all-in-one image, and starts it behind Caddy with all four volumes wired up. You configured a production environment by editing one line in a text file, which is one line more configuration than I'd prefer, but I can live with it.

Step 2: Wait, and why waiting is fine

First boot takes 15 to 20 minutes, and your domain answers only when it's done. Most of that time is the Angular production build, which is slow by nature and unbothered by your schedule.

I'm giving this its own section because every tutorial skips it, and every reader hits it. During those minutes your domain refuses connections. If you're behind Cloudflare, you'll see a 521. Your reflex will be that something broke. Nothing broke - this is the expected state, not a failure. Caddy retries certificate issuance on its own, so HTTPS comes up by itself within minutes of DNS propagating.

If you can't stand not watching, SSH in and follow along:

tail -f /var/log/cloud-init-output.log

When the log goes quiet and the build is done, your domain serves the login screen. Over HTTPS. With a real certificate you never requested, configured, or renewed.

Step 3: Log in and rotate the keys

Browse to https://your-domain/ and log in with root / root. The frontend loads the setup wizard automatically, which walks you through changing your root password, optionally adding your OpenAI API key for the AI features, and optionally configuring additional database connections.

The detail worth pausing on: when you change the password, the system also replaces the default JWT secret with a freshly generated one and persists it to the config volume. Most platforms put "rotate your secrets" in a hardening checklist you'll read never. This one does it as a side effect of the one thing every human does anyway - changing the default password. Security that happens by default beats security that happens by discipline, every single time.

Because config and data are persistent volumes, your new password, your JWT secret, and your database all survive reboots and upgrades.

Day 2: Upgrading later

"Sure, deploying is easy - but what about maintaining it?" - the standard objection to every simple setup. Here's the entire maintenance story. SSH in and run:

cd /opt/magic
git pull
docker build -f .do/Dockerfile.backend -t magic .
docker rm -f magic
docker run -d --name magic --restart unless-stopped --network magicnet \
  -v magic_files_etc:/magic/files/etc \
  -v magic_files_data:/magic/files/data \
  -v magic_files_config:/magic/files/config \
  -v magic_files_modules:/magic/files/modules \
  magic

Caddy keeps running untouched, certificates and all. And the content rules on container start are deliberately boring: the frontend folder is overwritten from the new image - overwrite only, your own web files are never deleted. Platform folders come fresh with every upgrade. Everything else - data, config, modules, your files - is copied from the image only if missing, and never touched if it exists. Your data outlives every container you'll ever run.

The numbers

Time for the section you knew was coming.

The one-copy-paste path: $12/month for 1 vCPU / 2 GB, or ~$24/month for the comfortable 4 GB plan. Add 20% if you want droplet backups. Worst realistic case: under $30/month, all-in.

The orthodox path: a minimal managed Kubernetes setup starts around $150-300/month before you've deployed anything, and that's the cheap part - the expensive part is the human who understands it. Even a fraction of one DevOps engineer's time costs more per month than a decade of this droplet.

And the AI part - the Hyperlambda Generator, which writes backend endpoints from plain English - currently costs nothing. The repository lists future pricing at $49 per 1,000 requests, but today there's no payment wall at all. So the complete stack, AI code generation included, runs at the price of three coffees a month.

The honest version

One droplet is one droplet. There's no high availability, no autoscaling, and if the datacenter region has a genuinely bad day, so does your backend until you restore from backup. If you're running payment infrastructure for millions of users, this is not your architecture, and I won't pretend otherwise.

But here's the uncomfortable truth for the orthodoxy: the overwhelming majority of business backends fit comfortably inside one droplet of this size, and always will. Droplet backups exist. Restores work. And you can graduate to the complicated architecture when you have the problem it solves - not preemptively, because a conference talk scared you into cosplaying Google.

Until that day, your entire DevOps department is a text file with one edited line.

Get started with Magic Cloud, grab the code on GitHub, or talk to us if you'd rather we deploy it with you.