RailRocket
About RailRocket

We built this because we kept losing days to local dev.

RailRocket is a cloud development environment built by two people in Berlin. It started in 2024 because we’d both spent too many evenings rebuilding Docker images for someone else’s laptop.

The annoyance that became a company.

At one of our previous jobs, the new-hire onboarding doc was 47 pages and ended with “ask Lukas if it doesn’t work.” That document had been growing for four years. Half the pages were workarounds for the workarounds. Three quarters of the workarounds were operating-system-specific. Anyone joining had to budget two days of setup before they could even check out the codebase.

Once you were set up, you immediately had a new problem: keeping your local environment in sync with everyone else’s. Postgres versions drift. Node versions drift. The colleague who solved that flaky test last month forgot to write it down. The CI passes, the local fails, and you waste an hour on environment archaeology.

Cloud dev environments solved this for some companies (mostly large ones with internal platform teams). For small teams, the options were limited — the tooling was either too heavy, too expensive, or required you to give up your editor.

$ railrocket workspace create feat/login-redirect
  snapshot restore: 0.4s
  npm install (cached): 0.8s
  postgres restore: 0.2s
  ✓ ready in 1.4s

What it turned into.

RailRocket gives every Git branch its own workspace. The workspace is pinned to the branch. Open a PR — a workspace appears. Push a commit — the workspace rebuilds. Close the PR — the workspace tears itself down. There is nothing to babysit.

Workspaces snapshot in under 1.4 seconds because they’re not full containers being booted — they’re restored from a pre-built snapshot of your specific repo and config. You can attach with VS Code in your browser, JetBrains via Gateway, or your local terminal’s vim over SSH. You can share a workspace by URL.

Configuration is one file in your repo — railrocket.yml — that defines the workspace shape. Same config, every dev, every branch.

How we run the company.

We’re two people. We’re bootstrapped. We’ve been customer-funded since month three. Our growth target is “keep both salaries paid and reinvest the rest.” That’s it.

What that means in practice: we don’t have a sales team, an SDR team, or a growth team. We answer email ourselves. Pricing won’t quietly increase to hit a quarterly target. We won’t pivot to AI agents because someone’s deck told us to. The product gets slowly better, the API stays stable, customers stay because we don’t hate them.

Who we are

Two people, both formerly at companies you’ve heard of.

LS
Lukas Schmidt
Co-founder · runtime & infra

Previously: platform team at SoundCloud (Berlin, 2018–2021), then infrastructure at HashiCorp (remote). Wrote the first version of RailRocket’s snapshot system over four weekends in 2024 because rebuilding Docker images had become unbearable.

HK
Hannah Klein
Co-founder · product & UX

Previously: design engineering at Figma (Berlin satellite office), then Linear (remote). Joined as cofounder in early 2025 after spending a month trying RailRocket as a customer. Now responsible for everything you see in the browser.

What we’ll keep

Three commitments we won’t walk back.

// stable

The API doesn’t break.

Once a CLI flag, config key, or API endpoint is documented in a release, it’s stable. New behaviour goes behind a new flag. We’ll deprecate before we remove, with at least 12 months of notice.

// honest

The free tier stays usable.

Hacker is not a trial. We won’t silently make it worse to push you to a paid tier. If we have to change the numbers, we’ll explain why and grandfather existing accounts.

// small

The team stays small.

We’re hiring slowly — one engineer in 2026. We aren’t targeting series-A scale. The product gets better because the people building it have time to think.