Shuttle

What Shuttle actually is

Shuttle is a Rust-only deployment platform with one genuinely different idea: infrastructure comes from your code's function signatures, not from YAML. You annotate your main function, ask for a Postgres database or a static folder as an argument, and shuttle deploy provisions the resource, wires the credentials and runs the service. No Dockerfile, no Terraform, no console session. In practice it behaves like a PaaS built by people who found container plumbing offensive — the code is archived, built on Shuttle's platform into an image, and started on AWS infrastructure in London (eu-west-2).

The company behind it is small and has been at this for a while. Shuttle went through Y Combinator's Summer 2020 batch (founded 2019), is headquartered in London, and raised a $6M seed round in October 2025 with an eye on extending the zero-config model beyond Rust to AI-assisted coding workflows. The scale numbers attached to that round — around 20,000 developers and 120,000 deployments — are meaningful for a niche language platform: this is one of the standard answers to "how do I host a Rust backend" and it has been for several years. The platform is open source, though self-hosting is still described as a future option rather than something you can run today.

The framework support is the practical draw. Axum, Actix Web and Rocket are first-class, and there are first-class recipes for Discord bots (Serenity) and other non-HTTP services. If you write Rust backends, the promise is that the distance between cargo new and a running public service is one annotation and one command. Compare the approach in our container platforms category; Shuttle sits at the far "developer experience first" end of that spectrum.

Pricing: what you really pay

Shuttle's pricing, revised in March 2025, is four tiers and it is unusually explicit about what each one contains. The Community tier is free forever: 0.25 vCPU, 0.5 GB RAM, one running project, 0.5 GB of database storage, 100 build minutes per month, seven days of log retention and custom domain support. The fine print matters: free-tier instances are spot instances that "may occasionally restart," which is fine for a hobby project and disqualifying for anything you would be embarrassed to have down.

Pro is $20/month plus usage, with a 14-day trial excluding usage. That buys reserved instances with full VM isolation, three included projects (up to ten), custom application metrics, logs and traces, 14-day log retention, 1 GB of included network egress and 0.5 GB of shared database storage, plus a stated one-business-day support response and migration assistance. Usage overage rates are published rather than negotiated: database storage at $0.12/GB, build minutes at $0.025/minute, network egress at $0.10/GB.

Growth starts at $250/month plus usage and is aimed at teams: ten projects (scalable to 50), horizontal scaling with up to ten replicas per project, rolling zero-downtime deploys, load balancing to 1,000 requests per second, a dedicated database, up to ten users, 30-day log retention and priority support over Discord or Slack with a dedicated channel. An Enterprise tier — bring your own cloud or single tenant, multi-region, custom SLA — is announced but marked "coming soon", so we would not budget around it yet.

The honest read: the free tier is real and usable, the jump from $20 to $250 is steep, and everything is metered on top of the base. For a solo developer running one small service, the cost is effectively zero to a few dollars. For a team, do the arithmetic on replicas, egress and build minutes before assuming the headline price is the bill.

Performance & infrastructure

Everything runs on AWS in a single region — London, eu-west-2 — according to Shuttle's own documentation. That is a clean, well-connected location for European users and acceptable for transatlantic traffic, but it means latency to US-west or Asia is what AWS routing gives you, and there is no region choice on Community or Pro today. Multi-region flexibility is listed as an Enterprise feature to come. The Growth tier's "multi-zone" language refers to redundancy within that region, not geographic choice.

On isolation, the tiering is clear and honest: Community runs on spot capacity that can restart, while Pro and above run on reserved instances with full VM isolation. That distinction is the single most important technical fact in the pricing table and we appreciate that it is stated plainly rather than buried. Builds are compiled on the platform, and the whole flow — cargo install cargo-shuttle, shuttle init, shuttle deploy — is CLI-first, with a console and templates for getting started.

Resource provisioning is where the design earns its keep. Adding a Postgres database is a macro annotation that hands back an authenticated connection pool; secrets, persistence and static folders work the same way. On the next deploy, the platform provisions and configures what the code asks for. For the workflow this targets — a developer (or an AI coding assistant) producing backend code and wanting it live — this removes an entire class of configuration errors.

What is not on the table: GPU workloads, bare metal, S3-compatible object storage as a first-class resource, IPv6 statements, or any published uptime SLA. There is no free-form compute; you run Rust services in Shuttle's runtime and nothing else. Monitoring on Community is limited to basic resource metrics through third-party integrations; Pro adds custom metrics, logs and traces.

Where it falls short

Rust only. The pricing FAQ answers this directly, and while the $6M round is explicitly about going multi-language, today a Go, Python or TypeScript team cannot use this platform at all. Even within Rust, you are committing to Shuttle's runtime and macro conventions: standard main becomes shuttle_runtime::main, and the deployment target is Shuttle's build pipeline rather than an artifact you control. The project is open source, which softens the lock-in concern philosophically, but self-hosting support is not something you can rely on today.

Single region. One AWS region in London with no choice on the paid-but-not-enterprise tiers is the biggest operational constraint. If your users are in North America or Asia, the fixed ~100 ms-class latency floor is a real cost. Enterprise multi-region exists only on a roadmap slide.

Maturity of the operational story. There is no published uptime SLA anywhere on the Community, Pro or Growth tiers — the custom SLA is an Enterprise "coming soon" item. Support is Discord-based for most users, with a one-business-day response promised on Pro. The March 2025 pricing revision also showed the other pattern young platforms have: tier contents move (Pro went from 15 projects to 3, egress from 10 GB to 1 GB), so budget against the current table, not a blog post you read last year.

Finally, spot instances on the free tier and usage metering above the base allocations mean the bill is predictable only if you watch it. Build minutes at $0.025/minute add up on teams that rebuild often.

Who should pick this

We would pick Shuttle when the deliverable is a Rust backend and the priority is shipping speed: side projects, internal tools, APIs behind an SPA, Discord bots, and the increasingly common case of AI-assisted code that needs a real deployment target within minutes. The infrastructure-from-code model is at its best when the developer does not want to become an infrastructure person, and the free tier is generous enough in compute terms (0.25 vCPU, 0.5 GB RAM) to run something real, restarts notwithstanding.

We would skip it for latency-sensitive services aimed outside Europe (single region), for anything needing a contractual uptime guarantee, for non-Rust stacks, and for teams whose traffic patterns make usage metering scary — a busy API on Growth plus egress can cross into serious money, and at that point a plain container platform with a region menu is the more controllable purchase.

Key takeaways

• Rust-only PaaS where databases, secrets and storage are provisioned from code annotations — shuttle deploy from the CLI, no Dockerfiles or Terraform.
• Pricing: free Community tier (0.25 vCPU, 0.5 GB RAM, spot instances), Pro at $20/mo + usage, Growth from $250/mo + usage, Enterprise "coming soon".
• Usage overages are published: $0.12/GB database storage, $0.025/build minute, $0.10/GB egress.
• All workloads run on AWS in London (eu-west-2); no region choice below Enterprise, no published uptime SLA.
• YC S2020, London-based, $6M seed (Oct 2025), ~20,000 developers and 120,000 deployments claimed; open source, self-hosting not yet practical.
• Our pick for Rust developers who value deploy speed over infrastructure control; not for multi-region production needs or other language stacks.

Sources

• https://shuttle.dev/blog/2025/03/19/pricing-update
• https://docs.shuttle.dev
• https://docs.shuttle.dev/pricing/faq
• https://www.ycombinator.com/companies/shuttle
• https://techcrunch.com/2025/10/22/shuttle-raises-6-million-to-fix-vibe-codings-deployment-problem