Upsun Alternatives

A design agency I know moved their client sites onto Platform.sh years ago and raved about one feature: every git branch got its own live preview environment, so a client could click a link and see the exact state of a feature branch. Then came the rebrand to Upsun, a move to usage-based pricing, and a bill review meeting that was noticeably less cheerful. Not because the platform got worse — the preview environments are still excellent — but because the bill had become something nobody could predict from one month to the next. I raise the story because it illustrates the specific failure mode of good PaaS pricing: nobody made a bad decision, the platform simply metered a behavior — branching, previewing, experimenting — that the old flat pricing had encouraged. When the product's best habit is also its biggest line item, it's time to look at the bill and the alternatives together.

That tension is what this page is about.

Here's the current shape of the product, at time of writing. Upsun is a managed application platform — container-based PaaS for PHP, Node.js, Python and roughly a dozen other runtimes — built on git-driven workflows where you push code and the platform builds and deploys environments. Pricing has moved to resource-based billing: reports describe an entry cost per project and per user (on the order of $9 per project and $10 per user per month, plus roughly $25 per app vCPU and $10 per GB of app memory monthly, with database services billed separately), billed per second, with a fixed-plan variant sold in euros from around €12 per month and up. Treat all of those as directional snapshots — Upsun publishes its rate card, and your architecture, not the rate card, determines the final number.

When it makes sense to leave Upsun

The bill is the first and most common reason. Usage-based pricing is honest in principle — you pay for what you use — but it concentrates cost in exactly the places growth touches: more environments, more users, more memory for the app that got popular. For a team with a handful of steady production apps, the predictability of a fixed-instance platform is worth trading away some elegance. Agencies with many clients on one account feel this hardest, because per-project and per-user charges multiply across the portfolio.

Watch the service sprawl too. A production app plus a staging clone plus a preview environment for each active branch plus a MySQL service for each is a beautiful workflow and a bill that scales with your team's branching habits. Developers who merge branches all day are effectively provisioning and deprovisioning resources all day. I've seen teams quietly reduce their use of the preview feature to save money, which is using the product against its own design.

The second genuine gripe is data custody. One recurring theme in reviews at time of writing is that platform backups aren't directly downloadable — you can restore within the platform but getting a full off-platform copy of your own data is harder than it should be. Whether or not that's still the exact policy, the underlying rule stands: your backup strategy should never depend on the same platform that could fail or that you might need to leave. If you can't get your data out on demand, that's an exit-cost problem sitting in your architecture today. My practical rule, on any managed platform: a monthly off-platform dump to storage you own, restored at least once to prove it works. It costs an hour a month and converts a hostage situation into a negotiation.

Third, support economics. As with most enterprise platforms, the support level you get tracks the support level you pay for, and uplifts for faster response or named contacts cost real money on top of the resource bill. If you're a small team on the basic tier, you may find yourself paying platform prices for ticket-queue support.

Support economics cut the other way at enterprise scale, to be fair: if you're paying for top-tier support and getting a named engineer who knows your architecture, the premium is defensible. The problem is the middle — small teams paying platform prices for shared queues.

Finally, category mismatch. If what you're actually running is a WordPress site, a static marketing site, or a single small API, a full PaaS is a Ferrari for the school run. The fixed costs — project fees, per-user seats, minimum service footprints — dominate the bill at small scale, and simpler platforms deliver the same outcome for a fraction of it. Half the "alternatives to Upsun" searches I see are people with a workload that never needed this much platform.

When you should stay

The preview-environment workflow is still the best in the business for the teams it fits. Every branch as a live, shareable environment with production data cloned underneath is a genuine force multiplier for agencies and product teams with client or stakeholder review processes. If your team ships through that workflow daily, replacing it means replacing a habit, and cheaper platforms don't have a true equivalent.

Stay if your stack is one the platform treats as first-class — PHP frameworks, Django, Node services — and your traffic is steady enough that the bill is stable month to month. Plenty of mid-sized teams have perfectly predictable Upsun bills because their architecture is predictable; the horror stories cluster around bursty, environment-heavy, multi-project accounts.

The managed runtime is the other real value: patches, orchestration, certificates, and scaling are handled, and the git-based build/deploy pipeline means every environment is reproducible from code. For teams without a dedicated ops person, that's the difference between shipping features and maintaining a Kubernetes cluster. European roots also make GDPR conversations straightforward, and enterprise procurement generally likes the platform's compliance posture.

And if you've sunk real work into the workflow — custom build hooks, environment variables management, deployment scripts, data fixtures for previews — the switching cost is months of re-engineering. An expensive-but-working platform beats a cheap migration that stalls.

The alternatives

Six-plus options from our database, organized by what your workload actually is. Prices are at time of writing and shift often in this category; several of these bill on usage too, so compare the shape of the pricing as much as the numbers.

Render — for straightforward web apps and workers

Render deploys web services, static sites, background workers, and databases from git with a clean dashboard and pricing that's mostly per-instance — the small instances sit in the low tens of dollars per month at time of writing, with a free tier for experiments. It's less magical than Upsun's branch environments and far more predictable per service. For a team that wants "push to deploy" without a platform tax, this is where I'd start.

Railway — for usage-priced simplicity

Railway bills by usage too, but the model is simpler and the dashboard is one of the best in the category — provision a database, a service, and a volume in a couple of clicks. Hobby-tier pricing has started around a few dollars per month plus usage at time of writing. If Upsun's per-seat, per-project layering is what you resent, Railway's flat simplicity is the direct contrast. The trade-off: fewer enterprise guardrails, a younger platform, and an ecosystem still gelling. For a small team that's usually the right trade; for a compliance-heavy organization it may not be.

Netlify — for static sites and the JAMstack

If a chunk of your Upsun footprint is marketing sites and front-ends, Netlify hosts static and frontend builds with a generous free tier and paid team tiers around the high-teens per member per month at time of writing. Pull that workload off the PaaS first — it's the cheapest, easiest cut from an oversized bill. Backend APIs can stay where they are.

Ploi — for PHP teams that want a managed server instead of a platform

Ploi takes the other approach: it provisions and manages servers on cloud providers you choose (including Hetzner and others) and runs your PHP/Laravel deployments on them, priced per server in the low tens of dollars per month at time of writing. You give up some platform magic and gain cost control, standard servers you can SSH into, and no per-environment metering. Agencies leaving Upsun over billing often land here.

Divio — for Django and Python projects

Divio is a managed cloud platform specialized in Django and Python applications, with environment-based workflows that will feel familiar coming from Upsun. If your portfolio is Python-heavy and the Upsun bill is the problem rather than the workflow, Divio keeps the developer experience closer than a plain server would. Compare its per-app pricing directly against your Upsun resource totals before deciding — and note that a specialized platform beats a generalist when your stack matches it, and frustrates you when it doesn't.

Ghost(Pro) — when the app is really a publication

A honest category check: if the "application" running on Upsun is a content site or a publication, Ghost(Pro) hosts managed Ghost from around the high single digits to a few tens of dollars per month at time of writing, scaling with membership size. Publishing is a solved problem; don't run it on a PaaS out of momentum.

Tiiny.host — for the static leftovers

The smallest possible landing spot: upload a zip of a static site or a PDF and get a hosted link. If some of your Upsun projects are one-page experiments and prototypes, they don't need a platform at all. Free and cheap tiers exist at time of writing, and it takes minutes rather than a sprint.

How to switch without downtime

Leaving a PaaS is less about DNS than about reproducing the environment — but the sequence still protects uptime.

1. Get your data out first, by hand. Whatever the platform's backup story is today, make your own: pg_dump or mysqldump the databases, export uploads and persistent files, and document every environment variable. The variable list is the hidden dependency — services authenticate, sign, and connect through values that live only in the platform's dashboard.
2. Write down what the platform actually does for you. Certificates, cron scheduling, queue workers, autoscaling rules, WAF, CDN — managed platforms bundle a lot of invisible labor. Every line on that list needs an owner on the new side, whether that's the new platform or you. Migrations fail most often on the ninth item nobody remembered.
3. Reproduce the build pipeline locally and on the new platform. Your build and start commands, the runtime versions, the cron tasks, the queue workers. On a per-instance platform like Render or Railway this maps to services; on Ploi it maps to a server plus deployment hooks. Rehearse the deploy until a fresh push from git brings up a working environment unattended.
4. Provision databases and copy the data, then set up replication or a final short sync if the workload can't pause. If the app can tolerate a short maintenance window outside business hours, a scheduled read-only window with a final dump is simpler and safer than live replication.
5. Keep the old platform running and cut DNS over deliberately. Lower TTLs a day or two ahead, point traffic at the new target during a quiet window, and keep the Upsun project alive as a rollback until you've watched production for a week or two. Remember you're billed per second, so keeping it alive briefly is cheap.
6. Rebuild the workflow you actually used. If your team relied on branch preview environments, decide consciously what replaces them — preview deployments on the new platform where available, or a lighter staging convention. Teams that skip this step end up missing previews in month two and resenting the move.
7. Wind down cleanly. Export anything remaining (logs, asset storage), verify your own off-platform backups restore correctly, then decommission the project and the user seats — the per-seat billing is the part that quietly keeps charging after people stop using the platform.

How we evaluate hosting providers

Everything on HostingSpotter starts from the same question: what will this cost me in year two? We weight renewal pricing above intro pricing in every comparison, because the intro price is a marketing budget and the renewal price is the actual product. Beyond that we look at resource limits as written in the terms — not the adjectives on the landing page — support responsiveness based on hands-on contact, data center location versus audience location, and how the provider handles the boring operational stuff: backups, certificate automation, and honest billing. Where I don't have a verified number, I say "at time of writing" and point you at the source, and I'd rather omit a figure than invent one. Nobody pays for placement here.