Railcode vs Vercel

Vercel is an amazing platform for deploying and hosting web apps. But it's a general-purpose platform, which means it's designed to support everything from public websites to large production applications.

Railcode is specifically built for internal software.

That means we're not not the place to host public websites or applications that need to be available to anyone on the internet.

Instead, Railcode is designed around a different assumption:

Anyone at a company should be able to build internal software fast without needing to manage infrastructure, credentials, or security.

For those use cases, Railcode gives Engineering and IT teams more control over what apps can access, enforces secure defaults by design, and gives coding agents a much smaller set of things they need to configure and reason about.

Comparison table

Security and control

Authentication

Every app deployed on Railcode is behind company authentication by default.

There's no way for someone to forget to add auth or accidentally deploy an internal app publicly. Authentication is always enforced by the platform for every app.

In addition, apps can be made available to:

• Only the person who built it
• Specific users
• Specific company roles
• Everyone in the company

These settings are native to the platform and can be changed with a simple CLI command or managed from the UI.

Roles and permissions

Beyond authentication, Railcode also offers centrally-managed roles and permissions.

These are configured once and exposed to every app, which means applications can use the company's existing permissions model instead of building their own.

For example, an internal app for keeping track of salaries and performance reviews can specify that the Exec and HR teams can see compensation for everyone, but everyone else can only see their own. This would be inheriting from the organization roles in Railcode and all other apps could do the same.

Define roles and permissions once, and they feed into every project built inside of Railcode.

External services

The same model applies when apps need to access external services.

For example, an admin might connect Stripe and allow the Customer Support role to view subscriptions and issue refunds, but not create new products or plans.

Members of the Customer Support role can then build apps using the Stripe connector that will be bound by those permissions.

Most importantly, they will never have access to a Stripe API key.

Here's an example:

// allowed
await connector("stripe").fetch("/v1/customers")

// blocked
await connector("stripe").fetch("/v1/products", {
    method: "POST",
    body: new URLSearchParams({
      name: "Premium Coffee",
      description: "Single-origin coffee, 250g",
    }).toString(),
});

Instead of handing out a Stripe key that could leak or be misused, Railcode keeps the credential outside the application and enforces the permission boundary at the platform level.

The same model applies when connecting a data warehouse like BigQuery as well.

An admin can connect BigQuery and expose specific queries (called "saved queries") to particular roles.

For example:

SELECT *
FROM customers
WHERE region = :region
LIMIT :limit

If a user has permission to use that query, their app can call it directly:

const rows = await query("customers_by_region", {
  region: "emea",
  limit: 100,
})

The person building the app doesn't need credentials for the warehouse, and they don't need arbitrary SQL access.

They only get access to the data capabilities an admin has explicitly made available to them.

That's the core security model behind Railcode:

Apps get capabilities, not credentials.

And because those capabilities are tied to centrally managed users, roles, and permissions, Engineering and IT can control what internally built software is allowed to do without having to review and configure every app individually.

Building speed and efficiency

Railcode was built for coding agents as much as it was built for humans.

The goal is to give agents a small set of predictable primitives they can use to build internal applications without spending time choosing, provisioning, and configuring infrastructure.

Every Railcode app gets its own project-scoped data store.

Apps also get file storage, email, LLM access, authentication, and managed connectors.

They're all available through the same SDK:

import { db, files, email, llm } from '@railcode/sdk'

// Database
await db.collection("products").put("coffee", { name: "Premium Coffee", price: 25 });

// File storage
await files.put("notes.txt", "Hello from Railcode")

// Mail service
await email.send({ to: "[email protected]", subject: "Welcome", text: "Hello!" })

// LLM Gateway
await llm.generate("Write a product description for premium coffee.")

There are no separate providers to choose from and no credentials to configure.

That matters because now the coding agent has no research or decisions to make, and it only needs to look at one set of documentation, so it can use fewer tokens and build faster.

On a general-purpose platform like Vercel, agents have complete flexibility.

They need to choose a database provider, an email provider, configure authentication, connect storage, manage environment variables, and fit all the pieces together.

Railcode also lets teams bring their own providers if they need to. The difference is that we provide common capabilities out of the box, so agents don't need to select and configure separate services for every project unless the team wants them to.

If someone asks an agent:

"Build me a tool for tracking customer escalations with file uploads, email notifications for account owners, and LLM summaries for escalations"

They won't need to do anything beyond that prompt, because the infrastructure primitives are pre-configured and ready to be used.

That gives Railcode three important advantages for internal software:

1. Apps require less setup
2. Coding agents have less infrastructure and documentation to reason about
3. Engineering and IT can manage the underlying capabilities centrally (and audit everything)

Instead of asking an agent to assemble an infrastructure stack every time someone needs a small internal tool, Railcode gives it a secure environment where the common pieces are already available.

And because those pieces are part of the platform, things like logs, permissions, connector access, and LLM usage can all be managed centrally instead of being scattered across a collection of unrelated services.

Summary

Vercel is a fantastic product and we're very inspired by their Developer Experience. We strive to be as great in that department as they are.

The Vercel platform is a great choice for deploying all sorts of applications, but being a general purpose platform it lacks useful primitives for internal software use cases.

Railcode, on the other hand, is focused exclusively on one use case, which allows us to cut scope and make tradeoffs that make Railcode the best possible solution for deploying internal software securely and fast.