Divio Alternatives

Divio is one of those platforms I root for. It's a Swiss, developer-focused platform-as-a-service built around Django and Docker — django CMS heritage, proper staging and live environments, real European data centers — and when I deployed a Django test project on it, the flow was exactly what you want: a Dockerfile-flavored setup, environment variables handled sensibly, a database attached without a support ticket. For European agencies with GDPR obligations and Django habits, it checks boxes that Heroku-style platforms never did.

But I've also watched two agencies move off Divio in the past couple of years, and both migrations came down to the same arithmetic: per-environment pricing on a platform aimed at professionals gets expensive as projects multiply, and for a lot of workloads there's cheaper ground to stand on. If you're at that decision point, here's my honest read on when to go and where to land.

When it makes sense to leave Divio

The cost curve as projects and environments multiply

Divio's pricing (roughly from $10/month per project at time of writing for the paid tiers, with a free developer account and trial above it — check their pricing page; the platform has reshaped plans more than once) makes sense for one serious application. It makes less sense at ten small ones, each wanting test and live environments and a worker. Container platforms and usage-based app hosts price idle environments at nearly nothing, and a small agency's total can drop by half or more by moving modest projects there. Price every project × every environment × every worker before renewing.

You don't need the Django specialization

Divio's value is Django-shaped: the buildpacks, the CMS integration, the environment tooling all assume a Django project. If your portfolio has drifted — Node services, static front-ends, Go workers, PHP remnants — you're paying a specialist platform's prices for a generalist's workload. General platforms (Render, Railway) run all of those natively.

Static and simple sites on the wrong machinery

A chunk of what agencies host is marketing sites, docs, and small front-ends. Running those through a Django PaaS is using a forklift for groceries. Static hosts like Netlify or GitHub Pages cost nothing and need no maintenance, and quick-throwaway hosting tools exist specifically for the tiny stuff. Freeing those off Divio shrinks the bill and the attack surface at once.

The platform's opinion becomes a constraint

Any PaaS abstracts the server, and Divio's control panel and workflow are its own shape. That's great until you need something the abstraction doesn't expose: custom infrastructure networking, a cron schedule the platform handles differently than you want, a specific database extension. Then you're filing feature requests and building workarounds. On a self-managed server (Ploi-style) or a low-level app platform, those are five-minute tasks.

Scaling economics for real traffic

Divio is built for professional project hosting, not hyperscale. When an application gets genuinely busy, vertically scaling managed app hosting gets expensive relative to container platforms or dedicated infrastructure. If your hosting bill tracks your traffic upward faster than your revenue does, the infrastructure pricing model is the problem.

When you should stay

If your work is Django and your clients are European, staying is easy to defend. The platform's Django competence is real — django CMS integration, sensible build/deploy, proper environment separation — and GDPR-friendly EU hosting with a Swiss company is a genuine compliance story, not a marketing sticker. The per-project price is also buying developer time: if Divio saves a few hours a month on deployment plumbing across your team, it's cheaper than the alternatives at any hourly rate you'd actually charge.

Stay too if the workflow is embedded in your agency's delivery process — client handoffs, environment promotion, the mental model your team has built. Migration costs weekends, and weekends cost more than most hosting deltas.

The alternatives

Railway — for usage-based app hosting

Railway is where I'd take a portfolio of small-to-medium apps: deploy from Git, attach databases and services in a click, and pay for actual usage rather than per-environment plans. Billing runs on a small platform fee plus usage at time of writing (their Hobby tier sits around $5/month with usage on top), and idle staging environments cost pennies. The trade-off is the usual PaaS bargain: less hands-on control than your own server, and costs can surprise you if a service spins hot — set budget alerts on day one. For agencies with many modest projects, the arithmetic usually wins.

Render — for teams wanting PaaS structure with predictable tiers

Render gives you web services, workers, cron jobs, and managed Postgres with a free tier for experiments and paid instance tiers starting at a few dollars a month at time of writing. It's the closest thing to "Heroku, but current" that I've tested — Git-based deploys, preview environments, sensible networking. Less Django-specific than Divio, more structured than pure usage-based hosts. If you want to leave Divio but keep the PaaS guardrails, this is the landing spot.

Ploi — for teams that want servers without server admin

Ploi sits at the other end of the spectrum: a management panel that provisions and maintains cloud servers (DigitalOcean, Vultr, Hetzner, AWS and others) for you — nginx config, SSL, deployments, queues, cron, backups. You pay Ploi for the panel (entry plans around the low tens of dollars per month at time of writing covering multiple servers) plus cheap server costs, and a whole agency's projects can live on one beefy server or several small ones. The dividend is control and cost; the tax is that the server is still yours under the abstraction — when something weird happens, you're closer to the metal. For a technical team, this is where the margins are best.

Netlify — for front-ends and JAMstack sites

If what you're actually hosting is a static front-end — Next.js export, Astro, Hugo, a docs site — Netlify does it with Git-based deploys, a generous free tier, and paid tiers when you need them at time of writing. Forms, functions, and edge features cover the dynamic bits small marketing sites need. Keep your Django API on an app platform and move the front-ends here; it's the split I see working most often.

GitHub Pages — for the free and genuinely simple

Documentation, project pages, small static sites: GitHub Pages is free, deploys from your repo, and needs zero maintenance. Custom domains and HTTPS included. No server-side code, no database — the moment you need those, you're somewhere else. But for a surprising share of "hosting" needs, free is not a compromise, it's the correct answer.

Ghost(Pro) — when the "application" is really a publication

A number of Divio-hosted projects I've seen are actually content sites — magazines, company blogs, documentation-with-a-CMS — running Django CMS because the team knows Django. Ghost(Pro) is managed Ghost hosting from the Ghost core team, starting around $9–$25/month at time of writing depending on tier and billing, with members, newsletters, and subscriptions built in. If the site is a publication rather than an application, a specialist publisher's platform is both cheaper and better at the job than a developer PaaS.

Tiiny.host — for tiny throwaway hosting

Not every project deserves infrastructure. Tiiny.host is drag-and-drop hosting for small static files and simple sites, priced in the free-to-few-dollars range at time of writing — perfect for client mockups, event pages, PDFs with a landing page, and prototypes you don't want to stand up a pipeline for. Obviously not an application host. But one of the best ways to cut a hosting bill is to stop paying serious-platform prices for unserious projects.

How to switch without downtime

Moving off a PaaS is smoother than moving off shared hosting in one way (your app is Dockerized or at least defined by code) and rougher in another (the platform's abstractions hide config you'll need to re-create).

1. Document what Divio gives you that isn't in your repo: environment variables, database credentials and extensions, cron schedules, file storage (media on a volume or object storage?), email sending, and any DNS records besides the main site.
2. Stand up the app on the new platform alongside — same codebase, staging URL, restored database dump. Django makes this mostly painless; test migrations, background workers, cron jobs, and media files, since those are the four things people forget.
3. Repoint object storage carefully. If media lives on Divio's storage, copy it to S3-compatible storage (which you should arguably be using anyway) and update the storage config. Media is the silent data-loss item in PaaS migrations.
4. Lower DNS TTLs a day ahead, flip at a quiet hour, and run both stacks in parallel for a week — keep the Divio project alive during overlap so rollback is a record change.
5. Verify: login flows, forms, transactional email (SPF/DKIM on the new sending path), background jobs executing, and database backups running on the new platform. Only then decommission.
6. Export everything before you close the account — code is in Git, but databases, media, and platform config live in Divio's systems. Download a final backup of each and store it yourself.

How I think about the portfolio hosting question

Agencies and freelancers rarely host one thing; they host a portfolio of projects with wildly different needs, and the cheapest way to host a portfolio is to stop treating it as one decision. This is the mental model I use for my own client work.

Sort every project into three buckets. Bucket one: static and trivial, marketing pages, docs, prototypes. These belong on static hosting that costs nothing and needs no maintenance, and the only question is which free tier fits. Bucket two: real applications with modest traffic, the Django projects, the small tools, the internal dashboards. These are the ones worth comparing platform pricing per environment, and where usage-based hosting or a managed panel often wins on total cost. Bucket three: the one or two projects where revenue and risk justify premium managed infrastructure. These stay on platforms with serious support, and the premium is insurance you're glad to pay when it matters.

Most teams I've worked with discover their portfolio is two-thirds bucket one after this exercise, which means the hosting bill shrinks before anyone migrates anything heavy. Moving five static sites to free hosting is an afternoon; moving one Django app is a project. Sequence accordingly.

Then total the invisible costs alongside the invoices: the hours per month deployment and maintenance actually take, the cost of an incident at your billing rate, and the context-switching tax of running too many platforms at once. I once consolidated a client's scattered projects onto fewer platforms at a slightly higher hosting cost and watched their true spend fall once time was counted. The spreadsheet decides, but only if the spreadsheet includes your hours.

The rule of thumb I end up with: pay premium prices for the projects that would hurt if they broke, pay usage prices for the ones that would merely annoy you, and pay nothing for the ones nobody would notice. A portfolio arranged that way stays affordable for years, and so does the team maintaining it. Re-sort the buckets once a year; projects move between them, and the hosting should move with them.

How we evaluate hosting providers

We evaluate platforms against the workloads they claim: for developer PaaS and managed application hosting, we deploy a real application (Django where it fits), wire up a database and background work, and watch both the deploy experience and the invoice — including what a second and third project does to the bill, since per-project pricing is where PaaS economics turn. Prices are quoted "at time of writing" with a source link because platform pricing moves constantly, and we call out free tiers and usage-based billing as what they are rather than folding them into a headline number. We weigh data residency, exit friction (can you get your data and your workflow out?), and support depth on real tickets. No provider pays for placement, and none sees a draft before it publishes — the HostingSpotter standard: show the real renewal pricing, or admit you don't know it.

Where I'd start

Sort the portfolio into buckets this week, before comparing a single pricing page. Move the static and trivial projects off first, because it's an afternoon and the savings are immediate. Then price the remaining applications on usage-based hosting versus a managed panel against your own hours, and keep the one or two revenue-critical projects on whatever premium platform earns its keep. Divio is a good home for the middle bucket if Django is your stack and Europe is your market — the right question was never which host is best, but which bucket each project belongs in.