App Hosting on Railway

Why the App Lives Somewhere Else

A marketing site can be plain files. An app cannot. When a service writer opens a job, adds a part and sends an estimate, something has to run code, check who they are and save the change. That is a server.

We run those servers on Railway. It takes a Node app from a Git branch, builds it and keeps it running. It restarts the app if it crashes. It holds the secrets, like database keys, out of the code.

The marketing site stays on the edge where it is fast and cheap. The app lives on Railway where it can think. Each piece sits where it does its job best.

How a Change Reaches Your Staff

The rule is short. Main is what runs. Nothing else ships.

1. A change is made on a branch and reviewed.
2. It merges into main once the checks pass.
3. Railway sees the new commit, builds it and swaps it in.
4. We open the health page and confirm the new commit is live.

That last step is the one people skip. A build can finish and the old version can still be running. So the app reports its own version. Here is a small Node server that does it. Railway fills in the commit for you.

import http from "node:http";

const port = Number(process.env.PORT) || 3000;
const commit = process.env.RAILWAY_GIT_COMMIT_SHA || "local";

http
  .createServer((req, res) => {
    if (req.url === "/health") {
      res.writeHead(200, { "content-type": "application/json" });
      res.end(JSON.stringify({ ok: true, commit }));
      return;
    }
    res.writeHead(404);
    res.end();
  })
  .listen(port);

If the commit on that page is not the one we just merged, the deploy is not done. It does not matter what any dashboard says.

Read the Build Log Before You Theorize

When a deploy fails, the first urge is to guess. Maybe a package changed. Maybe the server ran out of memory. Maybe it is the new code. An hour goes by trying fixes for problems that were never there.

The build log already knows. It shows the exact line that failed. Most of the time it is plain. A missing file. A typo in a start command. A secret that was never set.

So our rule is to open the real log before we form a single theory. Not a summary. Not the status badge. The raw text, from the top of the failing step. It takes a minute. It saves the afternoon.

If the log truly says nothing useful, we reproduce the build on a clean copy of the same commit. We do not debug the copy on someone's laptop, because that copy may hold files the server never saw. The server built from Git, so we test from Git.

The same goes for a crash after deploy. The runtime log shows the error and the line. We read it, then we fix it.

How the App Talks to the Rest of the Stack

The app is the middle of the stack. It does not work alone.

• Data. It reads and writes Postgres on Supabase. Row level security decides what each signed-in person can see. See the data layer.
• Messages. When a job is ready, it hands a text to the CRM, which sends it and logs it on the customer.
• Payments. It keeps track of what each customer has paid and what is still owed.
• The front desk. The AI front desk calls the same quote builder the staff use, so a price has one source.

Anything a customer is waiting on happens inside the request, in the app. We do not hand it to a timer and hope. A timer can run late. A request answers now. The jobs that can wait, like a nightly report, run on a server schedule. Automation and scheduling explains how we split the two.

What It Saves the Owner

Your staff do not notice deploys. The new version comes up and the old one goes away. If a change is bad, we roll back to the last good commit and the app is back while we fix the real problem.

You never pay for someone to patch a server's operating system. You never lose a day to a machine in a closet that stopped booting. And when something does break, you get an answer based on what the log said, not a list of maybes.

This is how Shop Desk runs. It runs a working auto repair shop, Supercanic, every day. The same setup runs RV Shop Desk.

What We Learned the Hard Way

Ship from Git, never from a laptop. Railway can upload a folder straight from a computer. That sends everything on disk, including files nobody committed. We once had a live app that matched no commit at all. It matched one person's unsaved work. Nobody could say what was running, so nobody could safely change it.

Now every deploy is a commit on main. If it is not in Git, it is not live. The health page proves it.

Second lesson. A green deploy does not mean the app works. It means the app started. We follow every deploy with one real action, like opening a job, to prove the thing people use still works.

Third. Secrets belong in the host, not the code. When a key changes, we change it in one place and redeploy. No file edits, no chance of a key landing in Git.

For the full routine, read deploy without breaking live. Next in the stack is CRM and phone, where your customers first reach you.