Elements vs Railway
Railway is a cloud hosting platform that runs apps and databases as containers, arranged as services on a visual canvas. You deploy each service from a GitHub repository, from a local directory with railway up, or from a Docker image, and Railway builds code into a container image with its Railpack builder or your own Dockerfile (builds). Postgres, MySQL, Redis and MongoDB deploy from templates as services in the same project (databases), and projects have environments, including temporary ones created for each pull request (environments). Railway charges a monthly subscription whose fee is credited against usage, and bills by the second for the CPU, memory and disk your services use, plus network egress (pricing).
Elements is not a hosting company. It is the software that makes and ships the app: a project server that runs while you work, a default framework with jobs and cron, a bundled Postgres database, a test runner, and a deploy command aimed at a plain Ubuntu machine from whichever provider you like, reached over SSH. You pay Elements a flat monthly price per machine for those tools, with no meter running (pricing).
Railway meters hosting, the part Elements treats as a commodity. It bills the CPU, memory and disk your services use, so the bill moves with your traffic, your background work and anything left running. Elements charges a fixed price for the tooling, and the tooling is what lets a deploy usually finish in under a second. What runs your app is a rented box with a sticker price.
At a Glance
| Elements | Railway | |
|---|---|---|
| What it is | Build, test and deploy tooling for an app on a server you rent | A usage-metered host for containers |
| What you pay for | Tooling, per machine, per month (pricing) | A subscription, plus CPU, memory and disk as they are used (pricing) |
| Where your app runs | A machine from DigitalOcean, Hetzner, AWS or another provider you pick | Containers on Railway's infrastructure |
| A deploy | Changed files only, usually under a second, into the running server | A new container image, built and booted by Railway before it replaces the running one |
| Tests and migrations | Every deploy tests the release against a freshly migrated test database, then migrates your data | Whatever you put in a pre-deploy command, run against your real database; no built-in test step |
| Background jobs and cron | A worker and scheduler inside the app, queued in a Postgres table | Another service on the canvas for each, metered by usage |
| Database | Bundled Postgres, installed and migrated by every deploy, or any Postgres host | A database template you configure and maintain |
| Moving away | Change a server address and deploy | Recreate each service, its variables and volumes on another host, and move each template database out |
Railway's Bill Moves With Your Usage
Railway's subscription covers a set amount of resource usage each month. Past that amount, CPU, memory and disk are metered by the second (plans). A busy week, a job that loops, or a service someone forgot to stop all show up on the invoice. To cut the cost of idle services, Railway offers app sleeping: a service that sends no outbound traffic for 5 to 10 minutes goes to sleep, and the next request waits for it to boot (app sleeping).
An Elements license costs the same each month however hard the app works. CPU seconds, builds and background jobs are not counted, so none of them can raise an Elements invoice (pricing, licenses). The machine comes from a provider's price list, and it never sleeps, so the first request of the morning gets an answer straight away.
No Container Image to Build or Boot
Every Railway deploy builds a new container image, whether it starts from a push to GitHub or from railway up, which uploads your project directory for Railway to build (CLI). However small the change, Railway boots the new container and then replaces the running one.
An Elements deploy has no image to build and nothing to upload wholesale. A copy of the project server lives on the deploy machine and remembers its build state from the last release. elements deploy opens an SSH connection to it, the two sides swap file lists, and a typical deploy carries a few KB of changed files. That server redoes only what those files touch, then switches releases by renaming a directory in one atomic step, so requests never wait on a restart or a cold process. Expect a few seconds the first time on a fresh machine, and under a second on most deploys after (what deploy does).
Your Tests See the New Schema Before Your Data Does
Code and schema change together, so the tests that matter are the ones run after the migration. Railway's pre-deploy command runs between building and deploying, for tasks such as database migrations, and if it fails the deployment does not proceed (pre-deploy command). It runs against your real database. Testing a migration before it touches your data would mean adding a second database service, migrating it first, and running your tests against it inside that command.
Elements ships that second database already wired in. A deploy compiles the release on every machine, migrates a test database, and runs your tests against the new schema there. Your real data is touched last: the first machine applies all pending migrations to the app database inside one transaction, and only after every test has passed. Should the compile, a test or a migration fail, nothing goes live and users stay on the release they already had (deploy, tests, migrations). elements deploy -json reports every result from every machine in one structured answer.
One Server Runs the App, Its Postgres and Its Workers
A Railway project grows by adding services to the canvas: the app, a database, a worker, a cron service, each billed by its own usage. Its Postgres is a template that Railway describes as "unmanaged, meaning you have total control over their configuration and maintenance" (Railway Postgres).
An Elements deployment starts complete. On the first deploy, Elements installs and starts Postgres on the server, the same Postgres you develop against locally, and every later deploy migrates it after your tests pass (setup). The same server runs the app, its job worker and cron, and a load balancer that issues and renews TLS certificates from Let's Encrypt (deploy). The job queue is a table in Postgres, cron uses Postgres to pick one machine for each tick, and realtime updates travel through Postgres LISTEN and NOTIFY, so there is no Redis service to add (jobs, channel). That bundled database covers a prototype or a one-server app. When the app outgrows one machine, or you would rather a provider ran backups and scaling, point DB_HOST at a hosted Postgres; Elements suggests DigitalOcean Managed PostgreSQL or Amazon RDS.
A second server makes a staging environment, deployed with elements deploy staging (environments). More servers pointed at one shared Postgres share the traffic, and each balances requests across all of them (load balancer).
Your Agent Finds the Broken Build Before Anything Is Uploaded
For an agent, every platform concept is one more thing to learn before it can ship. On Railway those are services on a canvas, templates for each database, Railpack or a Dockerfile, per-service variables and per-pull-request environments, and each is a boundary where the app and the platform can disagree. Between writing machine code and installing a package to subtract two numbers, the useful amount of tooling sits at the plumbing, and past it each new concept costs more than it saves. What pays off is correction, the agent learning what it got wrong while the mistake is still fresh.
On Railway, the build runs after railway up has uploaded your project or after a push reaches GitHub. A mistake shows up in Railway's build log, and your agent reads it there, fixes the code, and deploys again.
Elements moves that discovery to your desk. The server repeats a build your computer has already passed. The project server on your computer holds the build graph and build state in memory while you work, and on every save the build state is updated almost instantly: it builds in milliseconds and answers agents and humans in microseconds (build). After an edit, your agent asks with elements build -json and hears about each build error together, failing tests, migration problems and what type checking and program analysis catch, with no upload involved. Underneath it is SSH, Ubuntu and Postgres, which the agent already knows, and Elements ships as one coherent system, so one build stands behind every deploy. elements deploy will not start while the local build has errors (what deploy does).
Changing Servers Is a Config Change
Leaving Railway means recreating each service, its variables and its volumes on the new host. Leaving one VPS provider for another, with Elements, is a new address in config.jsoc followed by a deploy (walkthrough); data in the bundled Postgres travels as the SQL that elements db dump writes out (database cli). Nothing in the app is tied to a host. It is TypeScript, HTML, CSS and SQL, running on Node against standard Postgres, and its build, tests, jobs and deploy belong to Elements, so they move with it. @elements/app and the other runtime packages carry the MIT license (licenses).
Questions
What is the difference between Elements and Railway?
Railway is a hosting platform: it builds your services into containers, runs them on its infrastructure, and meters the CPU, memory and disk they use. Elements is not a host. It builds and tests your app, then ships it to a server you rent yourself, so hosting costs whatever that provider lists.
Is Elements a Railway alternative?
Yes, and nothing is billed by the second. Pair Elements with one rented server: Elements handles the build, the tests and the deploy, and that server hosts what Railway would split into services, meaning the app, Postgres, the job worker, cron, and a load balancer that issues and renews TLS certificates.
How much does Elements cost compared to Railway?
Railway charges a subscription credited against usage, then meters CPU, memory and disk by the second (Railway pricing). Elements charges a price per machine, per month, known up front and never metered (Elements pricing), and the server is rented from the provider you choose.
Can an Elements app use a Railway Postgres database?
Yes. An Elements app talks to any Postgres 16 or newer through DB_HOST, and the manual lists Railway among the hosts that work (setup). An Elements deploy also installs its own Postgres on the server, so a single-server app needs no separate database.
How fast is an Elements deploy?
Usually under a second, after a first deploy of a few seconds on a new machine. Only changed files travel, sent from your project server to the one on the deploy machine. The release goes live after the tests pass, into the running server, with no new container to build or boot.