Last updated 7 August 2026
Every platform below will run a Spring Boot jar. What separates them is whether their smallest tiers are large enough to be worth buying, whether the build cache makes a Gradle or Maven build tolerable, and whether the platform's assumptions about start-up time match a framework that spends its first several seconds scanning a classpath and constructing beans.
Two numbers dominate everything else. The first is memory: a modest Spring Boot service with a web layer, a JPA repository set and a connection pool wants something in the region of 512 MB to 1 GB before it is comfortable, because the heap is only part of the total — metaspace, thread stacks, the code cache and direct buffers all sit outside it. The second is start-up: seconds, not milliseconds, which makes scale-to-zero a much worse trade here than for any other stack we have compared.
The good news is that the JVM is an exceptionally well-behaved container citizen once configured, and Spring Boot ships production-grade readiness and liveness probes, graceful shutdown and layered image builds out of the box. The features you need from a platform are ordinary; you just need more of them.
The short version: Render and Railway are the most straightforward managed starts, Fly.io is cheapest if you accept that the headline machine is far too small for this stack, and Granite — our own platform — fits when the service belongs beside its Postgres or MySQL and its queue. If you are deploying a single small stateless API and price is the only axis, a compiled language on a 256 MB machine will always beat this, and our Go comparison says so.
At a glance
| Provider | From /mo | Free tier | Managed DB | Persistent disk | Deploy from |
|---|---|---|---|---|---|
| Fly.io | ~$2 | Postgres (unmanaged app) | Dockerfile, buildpack | ||
| Railway | $5 | yes ($1 credits) | Git, Dockerfile, template | ||
| Render | $7 | yes (spins down) | Git, Dockerfile | ||
| Granite | $9 | from Advanced | Git, Docker image | ||
| Koyeb | $29 | limited | Serverless Postgres | Git, Dockerfile | |
| Google Cloud Run | usage-based | yes (monthly allowance) | via Cloud SQL | no (use GCS) | Container image |
Entry prices as published by each provider on 7 August 2026, sorted cheapest first. Usage, bandwidth and databases are billed on top almost everywhere — treat this column as a starting point, not a monthly bill.
PaaS, serverless or a plain VPS?
A VPS is cheaper per gigabyte, and since the JVM wants gigabytes, the absolute gap is larger here than anywhere else in this series. That is the honest case for renting a box: the same money buys several times the memory. What you keep is the responsibility — kernel updates, TLS, rollouts, and database backups you have actually tested restoring.
Serverless is the weakest fit of the three categories, and it is worth being blunt about why. Scale-to-zero is a trade: you save money while idle and pay for it in cold starts. For a Go binary that trade costs milliseconds; for Spring Boot it costs seconds of classpath scanning and bean construction, paid by a real user. The exception is a GraalVM native image built with Spring AOT, which starts in tens of milliseconds — genuinely excellent, at the price of a long, resource-hungry build and reflection configuration for anything dynamic.
A managed platform is where most production Spring Boot ends up, because the workload is the shape platforms are best at: a long-lived process with a steady memory profile, a managed relational database beside it, and a build step that produces an image. There is no cleverness required — only enough memory, and a health check pointed at the right endpoint.
A long-lived service with a database behind it — the normal case
Managed platform
Steady memory, a managed Postgres or MySQL beside it, and nothing to operate.
Granite · Render · Railway
Bursty traffic, and you are willing to build a GraalVM native image
Serverless
Tens of milliseconds to start — the only way scale-to-zero and Spring coexist.
Cloud Run · Koyeb
Memory is the binding constraint and you are happy running the machine
Plain VPS
Several times the RAM for the same money — and every operational duty stays yours.
Hetzner · DigitalOcean · anyone
The options
Fly.io
- Best for
- Teams comfortable running their own database who want several regions and per-second billing.
- Pricing
- Pay as you go. The smallest shared-cpu-1x machine with 256 MB RAM works out at roughly $2.02/month, billed per second.
- Takes your Dockerfile, so the JDK version, the garbage collector and the JVM flags are entirely yours.
- Multi-region deployment and Anycast routing are first-class.
- Per-second billing, so stopped machines cost only storage — useful for staging environments that sleep.
- The headline ~$2 machine has 256 MB of RAM, which the JVM will not fit into comfortably; the price that makes Fly attractive for a Go binary does not apply to Spring Boot at all.
- Postgres or MySQL is a Fly app you operate and back up yourself.
- No free tier for new organisations since October 2024.
Railway
- Best for
- Getting a Spring Boot service, Postgres and Redis running together without configuring anything.
- Pricing
- Hobby is $5/month including $5 of usage credits; Pro is $20/month per workspace including $20 of credits. A free plan gives $1 of monthly credits, and there is a 30-day trial.
- Builds a Gradle or Maven project without a Dockerfile, and caches dependencies between builds — which matters more here than for any other stack, because a cold dependency resolution is minutes.
- Postgres and Redis sit in the same project and are reachable privately.
- A free plan and a 30-day trial for evaluation.
- Usage-based billing on top of the base fee is hard to forecast, and a JVM's steady memory footprint consumes credits faster than a lighter stack does.
- The Pro fee is per workspace, which adds up for small teams.
Render
- Best for
- A conventional Spring Boot deployment with a predictable monthly bill.
- Pricing
- Free web services are available but spin down after 15 minutes without traffic. The cheapest paid instance, Starter, is $7/month for 0.5 vCPU and 512 MB RAM.
- Simple fixed instance pricing, which suits a workload whose memory use is high but very stable.
- Managed Postgres and Redis, plus background workers and cron jobs in one account.
- Health check paths are configurable, so Actuator's readiness probe can drive traffic routing properly.
- The $7 Starter tier is 512 MB — usable for a small service with tuned JVM flags, but the first tier that feels comfortable costs meaningfully more.
- The free tier spins down after 15 minutes, and a JVM cold start is the slowest in this series, so it is close to useless for anything but a demo you warm up first.
Granite
- Best for
- A Spring Boot service that belongs beside its database and its queue, with room to grow into.
- Pricing
- Hobby is $9/month and includes $15 of monthly usage credits. Advanced is $39/month with $50 of credits, Professional $149/month with $200. Every plan has unlimited workspace seats.
- Managed Postgres and MySQL — both first-class assumptions in the Spring ecosystem — plus Valkey, all over internal DNS with no public endpoint.
- Deploy a prebuilt image from CI or let the platform build from Git, so a slow JVM build can happen wherever it is cheapest for you.
- Web service, a worker consuming a queue and scheduled jobs are separate resources built from one image, so they share configuration and deploy together.
- A private Docker registry in the same project, which suits teams already building layered jar images in CI.
- Flat plan pricing with unlimited workspace seats, so team size never changes the bill.
- No free tier — the cheapest way in is $9/month.
- The Hobby plan caps at 1 GiB per service, which is a real ceiling for the JVM rather than a theoretical one; Spring Boot reaches the Advanced plan sooner than lighter stacks do.
- Fewer regions than the hyperscalers, and no multi-region routing yet.
Koyeb
- Best for
- Edge presence for a service where the entry price is acceptable and traffic is steady.
- Pricing
- The Pro plan is $29/month; Scale is $299/month. Serverless Postgres has a small free allowance.
- Edge locations included rather than sold separately.
- Managed Postgres available without leaving the platform.
- The highest entry price of any managed option here.
- Scale-to-zero is close to unusable for a JVM service: the wake-up is seconds of classpath scanning and bean construction, landing directly on a real request.
Google Cloud Run
- Best for
- Teams already inside GCP, or services compiled ahead of time to a native image.
- Pricing
- No monthly fee. You pay per request and per resource-second, with a monthly free allowance. Cloud SQL and networking are billed separately.
- Takes any container image, and the second-generation execution environment runs a JVM without surprises.
- Effectively unlimited scale ceiling, with per-request billing for genuinely spiky traffic.
- A GraalVM native image built with Spring AOT starts in tens of milliseconds, which is the one configuration where scale-to-zero and Spring genuinely fit together.
- Without a native image, cold starts are seconds and min-instances is the only fix — which removes the saving that justified the platform.
- Native image builds are slow, memory-hungry and require reflection hints for anything dynamic, so the fix has a real cost of its own.
- Database, secrets and networking are separate GCP products you assemble and bill separately.
What a Spring Boot app actually needs from a host
- Tell the JVM it may use the memory
- In a container, the JVM sizes the maximum heap as a fraction of the memory limit — a quarter by default on a machine of any size. On a 1 GB instance that means roughly 256 MB of heap while you are paying for four times that, and the application starts throwing OutOfMemoryError with three quarters of the container unused. Set MaxRAMPercentage explicitly, and remember the heap is not the total.
- Memory is more than the heap
- Metaspace, thread stacks, the JIT code cache, garbage collector structures and direct byte buffers all live outside the heap and are all counted by the container limit. Budget several hundred megabytes above your maximum heap, and treat any tier under 512 MB as unsuitable for a conventional Spring Boot service.
- Cold start is seconds
- Component scanning, auto-configuration and bean construction take a real amount of wall-clock time before the first request is served. That makes any feature built on frequent restarts — scale-to-zero, aggressive autoscaling, spot instances — considerably more expensive here than for a compiled binary. Prefer platforms where the process simply stays up.
- Layered jars and build cache
- A fat jar rebuilt as one layer means every deploy pushes and pulls the whole thing, dependencies included. Spring Boot can produce a layered image where dependencies, loader and application code are separate layers, so a code-only change ships a few megabytes. Combine it with a platform that caches the Gradle or Maven dependency directory between builds, or every push pays for a full resolution.
- Actuator probes, not the root path
- Spring Boot exposes separate readiness and liveness endpoints under Actuator once probes are enabled. Point the platform's health check at readiness rather than at the root: an application that is listening but has not finished connecting its datasource will happily answer a TCP check and fail every real request for the first few seconds after a deploy.
- Graceful shutdown, matched to the platform
- Enable graceful shutdown so in-flight requests finish when SIGTERM arrives, and set the shutdown phase timeout to less than the platform's grace period. If the platform kills the container after ten seconds and your timeout is thirty, you have configured a slower failure rather than a graceful one.
- HikariCP against the database ceiling
- The default pool holds ten connections per instance. Three replicas is thirty, plus whatever else connects to the same database, and managed Postgres instances at the small end have modest connection limits. Size the pool deliberately — a smaller pool with queuing usually behaves better than a large one that exhausts the server.
- Migrations and the replica race
- Flyway and Liquibase both take a lock before applying changes, so concurrent replicas will not corrupt the schema — but they will all wait, which turns a deploy into a slow rolling start. Running migrations as an explicit release step before the new version boots is still the better pattern where the platform offers one.
So which should you pick?
A conventional service with a database, least ceremony. Render. Fixed pricing suits a workload whose memory use is high and stable, and the managed Postgres is in the same account. Budget above the Starter tier.
The fastest path to a running stack. Railway, whose build cache takes the sting out of Gradle and Maven and whose templates wire the database up for you.
A service that belongs beside its database and its queue. This is where we would argue for Granite. Managed Postgres or MySQL and Valkey run in the same project over internal DNS with no public endpoint, you can push a layered image built in your own CI to the private registry rather than paying for a JVM build on every deploy, and the service, its queue consumer and its scheduled jobs are resources from one image. From $9/month — though for this stack, plan on the Advanced plan and its larger per-service memory rather than Hobby.
Genuinely bursty traffic, and you will invest in a native image. Cloud Run with a GraalVM native image built through Spring AOT. It is the one combination where a Spring application scales to zero without punishing the next visitor — as long as you accept a slow build and reflection hints as the price.
Comparing runtimes rather than platforms? The Go and Django comparisons cover the same providers at very different memory footprints, and the app platform page covers prebuilt images, workers and cron jobs.
Hosting for other stacks
Six ways to run a Go binary, from a $2 machine to scale-to-zero — and why Go stays cheap longer.
Seven options weighed on the things Django actually needs: media storage, a real Postgres, Celery workers and enough memory for gunicorn.
Vercel and six alternatives, weighed on the things that actually break when you self-host: ISR across replicas, image optimization and build-time env vars.
Six platforms plus Kamal, weighed on what Rails really needs: a release phase for migrations, a job runner, Active Storage and enough memory for Puma.
Laravel Cloud and six alternatives, weighed on queue workers, the scheduler, writable storage and the caches you must rebuild on every deploy.
Six platforms weighed on what an ASGI service actually needs: worker processes, connections that stay open, and a database pool that does not multiply out of control.
Seven options for the framework that ships no opinions — weighed on the WSGI server you have to bring, the session key you must keep stable, and the extensions that decide the rest.
Six platforms weighed on the things Symfony assumes: a warmed cache built at build time, Messenger workers that restart on deploy, and Doctrine migrations that run exactly once.
Seven platforms for a framework that renders on every request — weighed on streaming, adapters, and how far the loaders sit from the database.
Six places to run a container image, compared on what actually bites: architecture mismatches, registry access, signal handling and the volume you assumed would still be there.
Five ways to serve HTML that is already written — and an honest note about which of them we are not the right answer for.