# 9 Render Alternatives in 2026, Compared by Operator > Nine Render.com alternatives for backends: who operates each, how billing differs, why Frankfurt isn't EU hosting, and what render.yaml won't move. 1. [Home](/) 2. [Blog](/blog) 3. 9 Render Alternatives in 2026, and What Your render.yaml Doesn't Carry DeploymentSeptember 26, 202613 min read # 9 Render Alternatives in 2026, and What Your render.yaml Doesn't Carry Nine platforms that replace Render.com, sorted by who operates them and how the bill differs from Render's, plus a line-by-line read of what a render.yaml moves and what it quietly leaves behind. ## The short version Pick the destination by the problem that sent you looking. Railway and Fly.io meter usage instead of charging for an instance tier, which changes the bill but not the jurisdiction. Coolify on a rented European server shrinks the invoice. Clever Cloud, Scalingo and Upsun answer a customer asking whose law governs their data. Then read your render.yaml line by line, because generated secrets, sync: false values and disk contents never leave Render on their own. [Teo Marquardt](/about#author)· Facts last checked September 26, 2026 The short version first. Railway is the closest lateral move if you want usage billing instead of instance tiers. Fly.io suits an app that has to sit near users on several continents. Northflank adds production controls and can run inside a cloud account you own. Coolify and Dokploy on a rented European server cut the invoice furthest and hand you the server. Clever Cloud, Scalingo and Upsun are run by French companies, which is the property that changes the answer when a customer asks whose law applies to their data. Sliplane runs your container in Germany and not much else. Runsite, which publishes this page, runs in Germany, is operated by one person rather than a company, and reads a render.yaml directly. Most Render alternatives lists are written by one of the platforms on them, and each one comes first in its own ranking. This one is no different in that respect, so the table below sorts on two things that do not depend on who wrote it: where the operating company is registered, and how the bill is shaped compared with Render's. After that comes the part the lists skip, which is what inside your `render.yaml` survives the trip. ## Render alternatives for backend services: nine options in 2026 Render bills in two layers. There is a workspace plan ($0 for Hobby with one seat, $25/mo for Pro, $499/mo for Scale), and then each service runs on a fixed instance type, such as $7/mo for 0.5 CPU and 512 MB, [prorated to the second](https://render.com/pricing). Postgres, Key Value and disks are priced separately, and bandwidth beyond the included 5 GB (Hobby) or 25 GB (Pro) is $0.15 per GB. Every row below is described relative to that. | Platform | Where the operator is registered | How the bill differs from Render | Best for | | ------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------- | | Railway | [United States](https://railway.com/legal/terms) (Railway Corporation) | Metered RAM, CPU and egress instead of instance tiers | Apps that idle most of the day | | Fly.io | [United States](https://fly.io/legal/terms-of-service/) (Fly.io, Inc.) | Per-second Machines that can stop when idle | Latency-bound apps in several regions | | Northflank | [United Kingdom](https://northflank.com/legal/terms) (Northflank Ltd) | Per-second usage, optionally in your own cloud account | Teams that want pipelines and to keep the infrastructure account | | Coolify / Dokploy | [Open source](https://github.com/coollabsio/coolify); you rent the server | Your server bill and nothing else | The smallest invoice, if you will run the box | | Clever Cloud | [France](https://clever.cloud/legal-notice/) (Clever Cloud SAS, Nantes) | Per-second, scales with load | A broad managed catalogue under an EU operator | | Scalingo | [France](https://scalingo.com/legal-notice) (Scalingo SAS, Strasbourg) | Per-minute, fixed container sizes | Workloads that face a security questionnaire | | Upsun (Platform.sh) | [France](https://upsun.com/trust-center/legal/impressum/) (Platform.sh SAS, Paris) | Project fee plus resources plus per-user licences | Teams that clone full environments per branch | | Sliplane | Germany (Berlin) | [Per server](https://sliplane.io/pricing), as many containers as fit on it | One container in Germany, nothing to administer | | Runsite | [Not incorporated](/compliance): sole operator, servers in Germany | Fixed plan per service, billed hourly from a prepaid balance, no workspace fee | Small teams leaving Render with a render.yaml in the repo | Nine alternatives to Render.com. Operator details link to each company's terms or legal notice; billing checked against each pricing page, Render's on 26 September 2026 and the others on 13 September 2026. ### 1\. Railway: usage billing instead of instance tiers Railway is the move people make when Render's instance tiers feel like paying for capacity that sits idle. It [meters the RAM, CPU, egress and volume storage](https://docs.railway.com/pricing/plans) a service actually uses, so a quiet app costs less than a $7 instance and a busy one costs whatever it used. The workflow is close enough to Render's that the first deploy is usually uneventful. The trade is the reverse of Render's: the invoice stops being a known number. How the two billing models fail, and in which direction, is laid out in [Render vs Railway](/blog/render-vs-railway). Railway Corporation is based in San Francisco, like Render. ### 2\. Fly.io: when the app has to be near the user Fly.io [bills Machines per second](https://fly.io/docs/about/pricing/) and its proxy can [stop an idle Machine and start it on the next request](https://fly.io/docs/launch/autostop-autostart/). That looks a lot like Render's free-tier sleep, except it is a setting you choose on a paid plan. Where Fly earns its place is geography: if your users are in Frankfurt, São Paulo and Sydney, it will put a copy of the app in each. If they are all in Europe, that capability costs you complexity and buys nothing. Fly.io, Inc. is a US company. ### 3\. Northflank: production controls, and the option to bring your own cloud Northflank shows up on Render shortlists because it covers the things Render's Pro plan charges for, like pipelines, preview environments and release controls, and because it can [run inside a cloud account you own](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank). The operator is Northflank Ltd in London. The UK is outside the EU and covered by an adequacy decision that [runs until 27 December 2031](https://eur-lex.europa.eu/eli/dec%5Fimpl/2025/2574/oj/eng), which is fine for most teams and a line item for anyone filling in a procurement form. ### 4\. Coolify or Dokploy: the smallest invoice, and you own the server These are control planes, not hosts. You install one on a server from Hetzner, Scaleway, OVHcloud or UpCloud and get a push-to-deploy dashboard with databases next to it. A backend that runs about $43 a month on Render (a $7 web service, a $7 worker, a $19 Postgres and a $10 Key Value) fits on a server that costs a fraction of that. What you take on in exchange is the operating system, the reverse proxy, certificate renewal, backups and upgrades of the control plane itself. That trade is priced hour by hour in [what self-hosting a PaaS actually costs](/blog/coolify-vs-managed-paas). ### 5\. Clever Cloud: a French operator with a wide catalogue Clever Cloud SAS, registered in Nantes, runs application runtimes, Docker, managed databases and object storage, with compute [billed by the second](https://www.clever.cloud/pricing/). It is the closest European match to Render's breadth. ### 6\. Scalingo: when the operator has to survive a compliance review Scalingo SAS in Strasbourg is built around being easy to put through a security review: a European operator, European infrastructure, and [ISO 27001 and HDS certification](https://doc.scalingo.com/security/overview/compliance). Most products are [billed by the minute](https://doc.scalingo.com/platform/billing/process). If the thing pushing you off Render is a customer's questionnaire rather than the price, this is the row that answers it most directly. What those reviews actually ask is covered in [GDPR data residency](/blog/gdpr-data-residency). ### 7\. Upsun: an environment per branch, data included Upsun, from Platform.sh SAS in Paris, treats an environment as something you clone: by default [a new environment inherits its parent's data and services](https://developer.upsun.com/docs/environments), databases included. Render's full-stack previews on the Pro plan are the nearest equivalent, but they start from seed data rather than a copy. Upsun's [billing has four parts](https://developer.upsun.com/docs/administration/pricing) (project fee, resources, per-user licences, add-ons), so model it before committing. ### 8\. Sliplane: your container on European servers Sliplane is a Berlin company that runs Docker containers on European servers, Germany and Finland among the locations, without asking you to administer the machine. It [bills per server rather than per service](https://sliplane.io/pricing), and one server runs as many containers as fit on it, which is the opposite of Render's one-line-per-service invoice. It has fewer managed services than Render, so a Postgres and a Key Value instance would need a home elsewhere or would run as containers you look after. If your render.yaml is one web service and nothing else, it is a short move. ### 9\. Runsite: reads your render.yaml, runs it in Germany Ours, with the limits first. Runsite is operated by an individual developer, not a registered company, so if your procurement review needs an EU company registration number, the three French operators above are the answer. There is one region, in Germany. Plans are fixed per service and billed by the hour from a prepaid balance, with no workspace fee on top. The entry points line up closely with Render's: a Starter [web service](/services/web-services) is 0.5 vCPU and 512 MB for €5/mo, always on, with 1 TB of bandwidth, against Render's $7 instance of the same size with 5 GB included on Hobby. Runsite can also import a render.yaml straight from your repository, which is described further down along with what it leaves for you to do. The column that decides it Three of the nine are run by US or UK companies, same as Render. Two are software you run yourself. Three are French companies, one is German, and one (ours) has no company behind it. Moving from Render to another US operator changes your bill and your dashboard and leaves the jurisdiction question where it was, in whichever region you deploy. If nobody has asked you whose law applies to your customers' data, ignore that column. If somebody has, it is the only one that matters. ## Why people leave Render The reasons show up at different points in a project's life, and the first one usually shows up on day one. The first is the free tier going to sleep. A free web service spins down after 15 minutes without traffic and [takes about a minute to come back](https://render.com/docs/free), which is fine for a side project and bad for a demo link or a webhook. Why that minute exists, and why every free tier has some version of it, is in [cold starts](/blog/cold-starts). The second is the bill adding up by the service. Each web service, worker, database and Key Value instance is its own line, and a modest backend with an API, a worker, a Postgres and a cache is four lines before anyone joins the workspace. Once a second person does, the $25/mo Pro workspace joins the invoice too, because Hobby has one seat. None of this is hidden; it just grows faster than people expect when they started on free. The third arrives later and has nothing to do with money: somebody asks which company processes the data and under which country's law. That is the subject of the next section but one. ## Is Render really free? Partly, and with clocks attached. Static sites are free to deploy. Free web services get [750 Free instance hours per workspace per month](https://render.com/docs/free); when those run out, every free web service in the workspace is suspended until the next month starts. A free Postgres database expires 30 days after it is created, with a 14-day grace period to upgrade before Render deletes it along with its data. A free Key Value instance does not persist to disk, so a restart empties it. Free services also cannot use persistent disks, SSH or outbound SMTP ports. So the free tier is real, and it is shaped for trying things rather than keeping them. The database clock is the one to watch, since the thing that expires first is the thing holding your data. ## Render Frankfurt is a region, not a jurisdiction Render offers [five regions](https://render.com/docs/regions): Oregon, Ohio, Virginia, Frankfurt and Singapore. Picking `frankfurt` puts the containers and the database in Germany, and it is a sensible choice for European users on latency alone. It does not change the company you have a contract with, which is Render Services, Inc. in San Francisco, and a US company's obligations under US law follow the company rather than the rack. Region is also fixed at creation. A service or database cannot be moved to another region later, and services in different regions cannot reach each other over the private network, so a region change is a migration even inside Render. If the reason you are reading this is a customer asking where their data is, the region answers half the question. The other half is who can be compelled to hand it over, and that part is covered in [EU vs US hosting](/blog/eu-vs-us-hosting) and, for the legal mechanics, [Schrems II and EU data transfers](/blog/schrems-ii-data-transfers). ## What's in your render.yaml, and what it doesn't know If you deployed with a [Blueprint](https://render.com/docs/blueprint-spec), your infrastructure is already written down, and that is a head start most migrations do not get. It is not the whole picture, though. A render.yaml describes the shape of your services. Some of what matters lives only inside Render, and the file just points at it. Here is a typical one for a small backend: yaml ``` services: - type: web name: api runtime: node region: frankfurt plan: starter buildCommand: npm ci && npm run build startCommand: node dist/server.js preDeployCommand: npm run migrate healthCheckPath: /healthz envVars: - key: DATABASE_URL fromDatabase: name: main-db property: connectionString - key: REDIS_URL fromService: type: keyvalue name: cache property: connectionString - key: SESSION_SECRET generateValue: true - key: STRIPE_SECRET_KEY sync: false disk: name: uploads mountPath: /var/data sizeGB: 5 - type: keyvalue name: cache ipAllowList: [] - type: worker name: jobs runtime: node startCommand: node dist/worker.js - type: cron name: nightly-report runtime: node schedule: "0 3 * * *" startCommand: node dist/report.js databases: - name: main-db postgresMajorVersion: "16" ``` Some of those lines move as they are. Some only make sense inside Render and have to be pointed at new resources. And a few were never really in the file, just referenced from it. | Line | Travels? | What to do before you leave | | ---------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | buildCommand, startCommand, healthCheckPath, runtime | Yes | Nothing. These are plain strings every platform has a field for. | | preDeployCommand | Yes, if the destination has a release step | Check the new platform runs it once per deploy before traffic shifts, not once per instance. | | fromDatabase, fromService | As references only | They resolve inside Render. The destination must create the database and cache first, then wire the new connection strings in. | | generateValue: true | No. The value lives only in Render | Copy the current value from the dashboard. A new platform will generate a different one. | | sync: false | No. The value was never in the file | Export these from the dashboard and set them by hand. | | disk | No | The contents are in neither the repo nor the database dump. Copy them out, ideally into object storage. | | plan, region | No, and they shouldn't | Plan names mean nothing elsewhere. Map by CPU and RAM, not by name. | | databases, keyvalue | The definition, not the data | The data needs a dump and restore. Plan this step first. | What a render.yaml carries to any destination. This is true whichever platform you move to, including ours. ### The generated secret that logs everyone out `generateValue: true` deserves its own warning because the failure is quiet. Render generated that value once, and it exists only in Render. Any import on the other side, ours included, will generate a fresh random value, which is correct behaviour and exactly what you do not want for certain keys. If it is a session secret, every user is logged out at the cutover. If it is the key your application uses to encrypt fields in the database, the restored data cannot be decrypted. Before you move, open each service in the Render dashboard, copy every generated value you care about, and set it explicitly on the destination. ### Workers, cron jobs and private services Render gives background workers, cron jobs and private services their own service types. Not every platform draws the same lines. Some run a worker as a second process in the same service, some want a separate service, and some have a scheduler but no internal-only service type. Before you commit, write down each non-web entry in your render.yaml and find where it lands on the destination. The one to be careful with is the cron job: if it is running on both platforms during the cutover, every scheduled email goes out twice. [Running cron jobs on more than one instance](/blog/cron-job-multiple-instances) covers how to keep that from happening. ### The data, which no manifest describes A Blueprint creates an empty Postgres. That is the right design, and it means the database move is a separate job with its own plan: a dump, a restore, a measured maintenance window and a way back if the restore goes wrong. Everything else in the file can be redone in minutes. The data cannot, so schedule backwards from how long the restore takes on a copy of your real database. On Render, [paid Postgres instances include logical backups](https://render.com/pricing), which is the natural place to start rehearsing. ## How Runsite handles it Runsite can import a render.yaml from a connected GitHub, GitLab or Bitbucket repository. You pick the repository and branch, it reads the file from the root, and it shows you a preview of everything it is about to create before anything is created. You can import into an existing project or let it create one from the Blueprint's project name. On the Runsite side it creates web services and static sites (Node, Python, Go, Ruby, Elixir, Rust or a Dockerfile), a [managed PostgreSQL](/services/postgresql) on the same major version for each database, and [managed Redis](/services/redis) for each Key Value entry. Build, start and pre-deploy commands come across, along with the root directory, health check path, auto-deploy setting, static publish path and Dockerfile path. The `fromDatabase` and `fromService` references get pointed at the new database, Redis and web services, and environment groups are expanded into every service that uses them. What it leaves for you is listed in the preview, not discovered later. `sync: false` values arrive as empty secrets waiting to be filled in. `generateValue` gets a new random value, so copy the old one first if it matters (see above). Background workers, cron jobs and private services show up as skipped. Disks, plan sizes, preview settings and the `networking` and `permissions` blocks are not imported, and with the newer `projects:` syntax only one environment comes across, `production` if there is one. The data doesn't move at all: the databases start empty, and the dump and restore are yours. After the import, pick plan sizes yourself; a like-for-like Render Starter is Runsite's Starter at 0.5 vCPU and 512 MB for €5/mo. Every new account gets €5 of credit, enough to run one entry-plan service of each type while you check that the import matched what you expected. Everything runs in Germany, nothing replicates outside the EU, and a signed [data processing agreement](/blog/what-is-a-data-processing-agreement-dpa) comes with every account. The subprocessors are named on the [compliance page](/compliance). ## The short version Choose the destination by the problem you actually have. If the complaint is paying for idle instances, Railway and Fly.io bill differently but leave you with another US operator. An invoice that's simply too big points to Coolify or Dokploy on a rented European server. A customer asking whose law governs their data points to Clever Cloud, Scalingo or Upsun, since a Frankfurt region on a US platform doesn't change that answer. Then read your render.yaml before you trust it. Commands and health checks travel fine, references need re-pointing, and generated secrets, `sync: false` values and disk contents live only inside Render until you copy them out. The database moves last, on a plan you rehearsed. If you want to see how much of that file comes across on its own, importing it into a [web service running in Germany](/services/web-services) takes a few minutes and shows everything it skipped before it creates anything. Related service ## Web Services on Runsite Deploy from a single git push and keep active apps warm — no cold starts, hosted entirely in the EU with a signed GDPR DPA on every plan. [Explore Web Services](/services/web-services) [Back to all articles](/blog) FAQ ## Frequently Asked Questions Common questions about this service. ### Is Render really free? Partly. Static sites are free to deploy, and free web services get 750 instance hours per workspace per month, after which all free web services in the workspace are suspended until the next month. A free web service spins down after 15 minutes without traffic and takes about a minute to wake. A free Postgres database expires 30 days after creation, with a 14-day grace period before Render deletes it and its data, and a free Key Value instance loses its data on restart because it is not persisted to disk. Free services cannot use persistent disks, SSH or outbound SMTP ports. It is a tier for trying things, and the database clock is the one to watch. All of this is as described in Render's documentation on 26 September 2026. ### Which is better, Vercel or Render? They are built for different shapes of application. Vercel is a frontend platform: static builds and server-rendered pages run as functions, and there is no long-running process of your own. Render runs long-lived containers, background workers, cron jobs and managed Postgres, so it can host a whole backend. If your app is a Next.js frontend talking to someone else's API, Vercel fits. If it needs a process that stays alive, a queue worker, or a database next to it, Render is the closer fit, and so is any of the backend-capable alternatives above. Both are US companies. What a full-stack app needs beyond a frontend platform is covered in the Runsite article on Vercel alternatives. ### How to use Render for free? Deploy static sites, which are always free, and use free web services for prototypes that can tolerate a one-minute wake after 15 idle minutes. Keep an eye on the 750 free instance hours per workspace per month, since running out suspends every free web service until the month resets. Do not keep data you care about in a free Postgres database: it expires 30 days after creation, and Render deletes it 14 days after that unless you upgrade. Free Key Value is fine as a cache but loses everything on restart. Once something has users, a paid instance is cheaper than the wake time it costs you. ### Is Render better than AWS? They sit at different layers, so it depends on how much of the stack you want to run. Render is a platform: you push code, it builds, deploys, restarts and patches the runtime, and you get managed Postgres without configuring it. AWS is mostly infrastructure: you get far more control and far more services, and you take on networking, IAM, patching and the deploy pipeline yourself or pay someone to. For a small team shipping a web app, a platform removes most of the operations work. The trade-off, including who is responsible for what under each model, is laid out in the Runsite article on PaaS vs IaaS. For European teams there is a second axis: both Render and AWS are US companies, whichever region you choose. Keep reading ## Related articles [Deployment12 min readRender vs Railway: Pricing, Free Tiers, and the Question Neither AnswersEvery comparison argues per-second billing against fixed instances. That axis is real, and it is not the one that decides where your data lives.Aug 12, 2026Read](/blog/render-vs-railway)[Deployment14 min read9 Railway Alternatives in 2026 — and What You're Actually Detaching FromNine platforms that replace Railway, compared by who operates them and how they bill — plus the four things inside your project that decide how hard the move is.Aug 13, 2026Read](/blog/railway-alternatives)[Deployment15 min read8 European Heroku Alternatives in 2026 — and How to Check One Really Is EuropeanEight Heroku alternatives operated by European companies, checked on the column the lists leave out: which company you contract with, and where it is registered.Aug 7, 2026Read](/blog/european-heroku-alternative) ## Your app deserves to be online €5 of credit on signup. Deploy in under a minute. No credit card needed. [Start deploying](https://dashboard.runsite.app/login)[View documentation](https://docs.runsite.app) --- Source: https://runsite.app/blog/render-alternatives