Deploy and Host Cap on Railway

Cap is an open-source screen recorder — record your screen and camera, get a shareable link in seconds, and let people comment on the timeline. It is the self-hosted alternative to Loom. This template deploys the full stack upstream ships: the web app, the ffmpeg media server that processes every recording, MySQL, and managed object storage for the video files.

About Hosting Cap

Three services and a bucket, all from official upstream images:

Web — the Cap application: dashboard, share pages, the API the desktop and mobile apps talk to, and the database migration that runs on boot. The only service with a domain.
MediaServer — ffmpeg. Transcoding, thumbnails, the preview GIF, audio extraction. Private; nothing outside the project can reach it.
MySQL — accounts, workspaces, recordings, comments, on a volume. Cap requires MySQL specifically.
Bucket — Railway object storage for the recordings themselves, uploaded straight from the browser.

All 37 variables are filled in and described on the deploy screen. There is nothing you have to supply — open the URL, enter your email, and you are in.

Four things this template does that are worth knowing about:

Recordings go to managed object storage, not a MinIO container. The obvious way to self-host Cap is the one upstream's compose file uses: MinIO on a volume, holding every recording anyone ever made, with nobody backing it up. Here they go to a Railway bucket. Getting that right took one measurement worth repeating — Railway storage answers both S3 URL shapes, but only the host/bucket/key form sends CORS headers, and Cap's recorder uploads straight from the browser. With the other shape every upload is refused in the browser while curl cheerfully reports 200. Verified here by requesting a presigned URL through Cap's own API, uploading to it, and reading the preflight response back.

Video processing actually finishes. Cap's media server reports transcoding progress by calling back into the web app over the private network, and that callback carries a shared secret. Two things have to be true for it to land, and neither is the default: the web container has to listen on the project's IPv6 private network — its image hard-codes an IPv4-only bind that no environment variable can override — and both services need the same secret, because the webhook route answers 401 when either side is missing it. Measured from inside the deployment: the callback returns 200 with the right secret, 401 with a wrong one, and 401 with none.

The images are pinned. Cap publishes only latest and beta — there are no version tags to pin — so this template pins the digest of both images instead. That is the difference between a redeploy that gives you what you already had and one that quietly swaps the application under a running instance.

MySQL is a supported version. Upstream's compose file ships MySQL 8.0, which reached end of life in April 2026. This template runs 8.4 LTS, supported into 2032, with binary logging and the performance schema switched off — neither is useful on a single-instance deployment and together they cost several hundred megabytes of RAM and a steadily growing volume. All 40 of Cap's database migrations were run against 8.4 before this template was published.

Common Use Cases

Async standups and updates: record two minutes instead of writing four paragraphs, and drop the link in the channel.
Bug reports that show the bug: a recording with the screen, the console and the reporter's voice, linked from the ticket.
Onboarding and support answers: a small library of walkthroughs on a URL you control, rather than in a vendor's cloud on a per-seat plan.
Recordings that cannot leave your infrastructure: customer screens, internal tooling, anything under a policy that rules out a hosted service.

Dependencies for Cap Hosting

Deployment Dependencies

Cap — the upstream project and its official images
MySQL 8.4 for accounts, workspaces and recording metadata
An S3-compatible bucket for the video files
ffmpeg, in the media server container

Implementation Details

Your login code appears in the deploy log. Cap signs you in with a six-digit code sent by email, and it sends email through Resend — there is no generic SMTP option. Until you set RESEND_API_KEY, the code is printed to the Web service's log instead, which is how you sign in for the first time: enter your email, open the log, read the code. It works, and it means anyone who can read your Railway logs can sign in as anyone. Add a Resend key before you invite people.
Anyone who reaches the login page can create an account — but they still need a code, which they cannot get. Set CAP_ALLOWED_SIGNUP_DOMAINS to your own domain once mail is configured, and that stops being theoretical.
New recordings are shareable by link by default, matching upstream. CAP_VIDEOS_DEFAULT_PUBLIC=false makes them private until you share them.
Migrations run in the web container on boot, and the start command waits for MySQL first. Railway starts services in parallel, so on a cold deploy the race is the default rather than the exception — and Cap gives up after three attempts.
The database is private. No public TCP proxy on MySQL; it is reachable only from this project's private network.
AI features are opt-in. Transcription needs an AssemblyAI key, summaries a Groq or OpenAI key, chat an Anthropic key. All four are on the deploy screen, empty, and nothing breaks without them.
The desktop and mobile apps point at this instance by entering your URL on their sign-in screen — the same URL you open in the browser.

Resource Usage and Cost

Measured on an idle deployment: about 550 MB of RAM across the three services — roughly 255 MB for the web app, 210 MB for MySQL and 85 MB for the media server — peaking near 1.3 GB during the first boot, while migrations run. Add the 5 GB volume MySQL is given and whatever the bucket holds.

That puts a quiet instance at roughly $10–20/month, but this is a product whose cost tracks use rather than uptime: transcoding is CPU-bound and happens on every upload, and video is the kind of thing that fills a bucket. Ten short recordings a week is a small bill; a team recording all day is not.

Why Deploy Cap on Railway?

Cap needs four things that are annoying to assemble anywhere else: somewhere to run the app, a database, a machine with ffmpeg on it, and object storage the browser can upload to directly over HTTPS. Railway supplies the last one as a managed bucket rather than a container you have to back up, gives the media server a private address the app can reach without exposing it, and hands out the domain and certificate before the first deploy finishes.

The alternative is a VM with a compose file, where MinIO's data directory, the TLS certificate, the CORS configuration and the restart policy are all yours — and where the first thing you meet is a web container that exited because MySQL was not up yet.