Overview

Railcode is the cloud platform for internal software. We make it easy for you to build custom software fast and share it with coworkers securely.

Think of Railcode as an internal Vercel for your company. Every project is deployed behind company auth. Permissions, connectors, and logs are managed in one place. And we provide the infrastructure building blocks you (or your coding agent) need to ship fast.

Builders get to build faster and with less friction. Engineering teams spends less time supporting one-off deployments, and can be sure that what gets built is secure.

The problem we're solving

Everyone can use coding agents to build now, so it's natural that people want to build tools that are useful to them and share them with teammates. A coding agent can write an internal tool in an afternoon. Getting it live is where the trouble starts.

Say you want to build an internal tool for triaging support tickets. At most companies, we have seen some version of the following:

• The app gets deployed on Vercel
• Data is stored on Supabase
• An API key for the relevant service (say, Zendesk) is handed to the builder
• Another API key is generated for OpenAI so the tool can have AI features
• Auth is hand-rolled, or a service like Clerk is added

Nothing here is wrong on its own. Now imagine (you might not have to, if you've lived through this) that you have ten projects like this. Or twenty. Or fifty.

• You hope auth was implemented correctly in every one of them
• Each tool has its own login and its own way of handling permissions
• Data is scattered across a dozen databases that nobody backs up
• There is no central cost tracking or logging
• Sensitive data and API keys might be sitting on the public internet

That's what Railcode solves. Your team keeps building the way they already do, only faster, and Engineering gets fewer requests for help. Every project inside Railcode is deployed behind company auth by default and inherits its permissions from the platform. The pile becomes an inventory. The next tool costs a deploy instead of a database, a login, and a security review.

Who it's for

If you're technical, Railcode is an internal Vercel. Every project is deployed behind company auth. Permissions and connectors are managed centrally. The building blocks are already there. We ship a CLI, and a skill so your coding agent can deploy and manage projects end to end. Every backend function also gets a zero-config SDK with per-project data and file storage, LLMs, governed connectors, email sending, and more. Basically, we take care of the annoying bits so you can focus on the fun part: building.

If you're not technical, Railcode lets you use your coding agent of choice to build apps and agents. They can automate processes, analyze data, or help you work with teammates. You can put them live for coworkers without asking anyone to set up hosting, a database, or a login. Tell Claude Code "build a Railcode app that reads our tickets from Linear and drafts a weekly summary", and your team can open the result tomorrow.

If you lead an engineering team, think of Railcode as a governed internal Vercel. Every app comes with company authentication by default. Data and file storage are per project, on one company account. Access to databases and SaaS tools goes through secure connectors that you configure once. There is one audit trail across all of it: who built what, who can open it, and what data it touched.

What we give you

The rails, so to speak:

What you build

A Railcode app is a static frontend plus a backend function, deployed and versioned as one unit:

you ──▶ Railcode proxy ──▶ frontend ──fetch('/api/…')──▶ your backend ──@railcode/sdk──▶ platform
        company auth         │                              │
                             no credentials            ctx.user (verified, unforgeable)
                             no authority              all authority lives here

The frontend is plain static files. It holds no credentials and proves nothing; it just calls your own routes. The backend function imports @railcode/sdk. That is where everything real happens: storage, database reads, third-party API calls, AI, email, and every authorization decision. So a rule like "X submits, Y approves, X can't approve their own" lives in code that a user cannot reach.

You own the code

You build with the tools you already use, like Claude Code or Codex. You own the code. You can run it locally and put it on GitHub. On Railcode the prototype is production: the tool you built this afternoon is deployed behind company auth the moment you ship it. There is no second project to "make it real".

Where to go next

• Want the mental model first? Read how Railcode works, then core concepts.
• Ready to ship? Start with the quickstart.
• Building something now? Read the app model and the backend SDK reference.
• Administering an org? Read organization administration.
• Maintaining an older app? Read legacy apps and migration.