Railway Review: I Used It as a Key Vault
for Fifty-One Cents

I didn't come to Railway looking for a hosting platform. I came looking for somewhere safe to put an API key.

That distinction matters, because it means this review can't tell you how Railway handles a production application under real traffic. I never put one there. What it can tell you is what the platform is like when you need one specific thing done properly, at the point where you're not yet sure the project is worth any money at all.

Why I Needed a Broker in the First Place

My day job is front-end web development. Our site had a search bar, and I'd never been happy with it. You'd type a question, and if nothing matched precisely it would grab a couple of your words and list every page containing them. That's the best case. Plenty of sites work exactly that way. I removed it from one version of the site entirely rather than ship something that unhelpful.

Then I started using ChatGPT for more than making pictures, and the thing that struck me wasn't that it was right. It was that it understood what I meant. If I could put that in front of our own documentation — our pages, our PDFs — people could ask a real question and get a real answer instead of a keyword dragnet.

The architecture for that is well understood: a vector database holding your documents in chunks, an LLM to phrase the answer, and retrieval joining the two. I used Pinecone for the database and Claude for the answers.

The problem is the part nobody puts in the diagram. Both of those services need API keys, and a key in browser-side JavaScript is a key you have given away. Anyone can open developer tools and read it, then spend your money until you notice. So something server-side has to hold the keys and make the calls on the browser's behalf.

That something is what I needed. Not a platform. A locked box with a door on it.

The Actual Setup

• Pinecone — three indexes holding our PDFs and site content, chunked and tagged.
• Embedding model in the browser — the visitor's own machine turned their question into a vector, so no server round-trip for that step.
• Flask API on Railway — the broker. It held both keys and made the outbound calls.
• Anthropic and Pinecone behind it — search first, then Claude to phrase the answer from what came back.
• A plain HTML page with an index switcher, so I could test against different document sets.

Railway sat in the middle of that, and its job was entirely unglamorous: hold two secrets, run a small Python process, and let a static page talk to it.

The Environment Variables Screen Is the Product

For what I was doing, Railway's environment variables panel was Railway. You paste your keys into a form, they live on the platform rather than in your code, and your app reads them at startup. That's the whole vault-door proposition, and the interface for it is about as simple as such a thing can be.

Deployment came from a GitHub repository. Push, and it builds and goes live. Over the life of the project I did that twenty-four times without ever thinking about the mechanics of it, which is the correct amount of thinking to do about deployment.

I also got notified about everything — maintenance windows, platform updates. I still get those emails, because I never closed the account. Some people would find that irritating. After a few years of hosting where the first sign of maintenance is your site being down, I find it reassuring.

The Number Nobody Publishes

The free trial gives you a one-time grant of $5 in credit, on a container with 1 GB of RAM, 2 vCPU and 1 GB of disk. That was more than enough for what I was running.

Here is the part I think is genuinely useful, because it's the number reviews never include. My dashboard still reads $4.49 of credits available. Across roughly a month of active development and twenty-four deployments, the entire proof of concept cost me fifty-one cents.

If you're evaluating whether an idea is worth pursuing, that's the relevant figure. Not the list price — what a real prototype actually consumes. For a small brokering service that sits idle between requests, it is close to nothing.

The Part Where I Was the Problem

I have to include this, because leaving it out would make the review useless.

I could not get the deployed app to read its environment variables. At the same time I was fighting a CORS error — the browser refusing to let my static page call the API. I was tired, both things looked like "the app won't talk to the thing it needs," and I concluded they were the same problem.

They weren't. CORS is a browser rule about which origins may call your API. Environment variables are server-side configuration read at startup, before any request exists. A CORS failure cannot stop a Python process from reading its own environment. I was chasing one bug with the fix for another.

So I did the thing you're not supposed to do: I put the keys in server.py and pushed it. It worked immediately, which is exactly what makes it dangerous. The repository was private, so I told myself it was fine.

It wasn't fine. Twenty-four commits of history each contain those keys. Private repositories get cloned to laptops, shared with collaborators, and occasionally made public by accident. When I sat down to write this review in July, I rotated both keys and revoked the originals — which is the only step that actually matters, because editing the file doesn't remove anything from git history.

None of that is Railway's fault. The vault worked; I walked around it. But a review that only describes the happy path isn't describing software use, it's describing a brochure.

A Redesign, a Lapsed Credit, and Five Dollars

Two things happened at once. The product I'd built the search for got redesigned, so I was back to the drawing board with a much bigger project. And the trial credit lapsed — Railway's grant expires 30 days after signup, which lines up exactly with my last deployment in late March.

Continuing meant the Hobby plan. It's worth being precise about what that is, because I had it wrong myself: Hobby is a $5/month subscription that includes $5 of resource usage — not $5 of credit on top of the fee. If you use nothing, you still pay the five dollars.

Which, for a project I couldn't yet prove was useful, I couldn't justify. I was already paying for Claude and a few other tools. I know how that sounds. I came up without money, and I still look at every recurring charge as if it's going to run out the door and take the rest with it. Five dollars a month is not a rational thing to agonize over. I agonized over it anyway.

So I went looking for a free way to hold a secret, and found that my existing hosting had a Node.js app manager with its own environment-variable screen. Included in what I already paid. I rebuilt the service in Node and moved on.

The Backtick

Months later, on a different project with the same hosting, I hit something I still think about.

I'd generated a long database password with special characters in it, as you should. One of those characters was a backtick. My host injects environment variables by writing them into a shell script that the Node wrapper evaluates — and a stray backtick opens a shell command substitution that never closes. The evaluation died partway down the file, and every variable after that point silently never loaded.

The app started. It reported itself healthy. It quietly fell back to a different storage backend and told me nothing. It cost me an evening, and I only found it by reading a log line that mentioned an unexpected end of file — in a shell script I didn't know existed.

Railway never did that. I pasted keys into a form and the app read them. Whatever is happening underneath, it never handed me a broken shell script to debug at midnight.

That's the comparison I can offer that most reviews can't, because I've now done both. The free option isn't free. It's priced in evenings, and you don't find out the rate until you're already paying it.

Who Should Use Railway — and Who Shouldn't

Worth it if: you need something small and server-side to hold a secret and make calls on behalf of a front end. You want to know whether an idea works before committing infrastructure to it. You deploy from GitHub and would like that to be the entire deployment process. Or you've reached the point where you'd rather pay someone five dollars than spend another night fighting your own server.

Probably not if: you have hosting that already does this well and reliably — no sense paying twice. Or your workload is large enough that usage-based pricing needs modelling before you commit, in which case the trial's $5 won't tell you much.

What I genuinely can't tell you: how it handles sustained production traffic, how the managed databases perform, whether the team features are any good, or how it behaves at scale. I ran one small Python service for a month. Anyone reviewing beyond their own experience is guessing, and you can usually tell.