Deploy a persistent browser on Railway

What the template sets up

Deploy and save your password

1. Open the Railway template

   Choose Deploy on Railway on this page and deploy the template into your workspace. Railway hosts the service and bills you for its resources.

2. Save ADMIN_SECRET

   In the deployed service's Railway variables, copy ADMIN_SECRET into your password manager. The template generates a different value for each deployment.

3. Open the dashboard

   Visit the service's generated domain and sign in with that secret. Check that the volume is mounted at /data before creating a browser.

4. Connect an agent

   Create an agent in the dashboard. Add https://YOUR_HOST/mcp to your MCP client with that agent's token, or complete the OAuth flow your client uses.

Configure upstream proxies per browser after deployment, rather than adding shared proxy credentials to Railway variables. The browser settings and credentials live in SQLite on /data. Credentials are unencrypted there, so protect volume access and backups.

Check one complete browser task

Ask your agent to create a browser and open https://example.com. Find it in the dashboard, choose Watch, then try Take control and Return to agent. This checks the tool connection and the live viewer before you add saved credentials.

For a persistence check, use a low-risk account. Sign in through takeover, stop the browser, and reopen that same profile. Later, confirm that a redeploy with the same volume attached also keeps the saved state.

Start small and watch resource use

Budget roughly 1–2 GB per active Chrome, plus the server, then measure your own pages. A heavy web app can use more. There is no browser cap by default; set TALLYLAMP_MAX_BROWSERS to bound it.

On Railway, processes usually run out before memory does. Railway gives each service 1,000 processes and threads, and every browser on it shares them. A Chrome on one quiet tab uses about 200, while one loading heavy pages can pass 600. Tallylamp counts each browser's share, holds a start until it fits, and stops idle browsers to make room. If one heavy run leaves a browser sized past what it needs, press Reset under Processes and threads on its page, and it is measured again.

The template also runs each Chrome on four CPUs. Chrome sizes its thread pools from the CPUs it sees, and a Railway container shows 48. In a ten-minute test on three heavy pages, four CPUs took one browser from a median of 346 threads to 203, with no crashed tab.

A Railway deployment uses one replica with its volume. Redeploys stop active browsers and have downtime. The saved profiles survive on the volume and Chrome starts again on the next use.

Keep a production browser up

Some browsers have to stay up, like a dashboard an agent reads all day. Pin one on its page in the dashboard. Tallylamp then holds room for it, so no other browser can start into that room. It stops idle browsers to start a pinned one, and it stops a busy one only when a running pinned browser is about to run short. It never stops a browser you have taken control of.

Pinning shares one service's 1,000. For a hard boundary, add a worker: a second service that runs browsers for your Tallylamp within its own 1,000. Open Workers in the dashboard, press Add worker, and deploy the Tallylamp Worker template into the same Railway project with the token it gives you. Then choose Move to… on the production browser. It stops, moves and starts again on the worker, with its logins, and you keep one dashboard and one MCP address. Full browser, tunnels and file uploads work there as they do on the main instance.

A browser on a worker cannot yet be saved as a saved profile. Keep a browser you want to save that way on the main instance.

A source push does not upgrade your service

The template uses a release image pinned to a digest, which identifies the exact image contents. Repository pushes and new releases leave your deployment on the version you selected. Read the release notes, back up /data, and change the image reference when you are ready to upgrade.