# Journey 68 free staging

Journey 67 has its own deployment. This project targets only the private staging application journey-68-free-staging, on its separate workers.dev hostname. Sign in with the staging username and password held by the owner. Only timetable status is publicly readable.

## Storage and daily processing

The standard GitHub-hosted Ubuntu job runs once a day at 07:23 UTC. It builds the existing SQLite index on the temporary runner disk, packages compressed station boards, compares the browser search with the SQLite results, then uploads a version to Workers Static Assets. The previous version continues to serve during processing. Each board contains all competing schedule versions for every train serving that station. The browser selects operating dates, resolves cancellations and alterations, then searches for direct and single-change trains in a background worker. The screen, live train overlay, interchange calculation and TfL connection use the existing Journey code.

The daily job has a 25-minute limit. At 31 runs that is 775 runner minutes, before manual runs, rounding or other repositories. Standard Linux compute at $0.006/minute draws up to $4.65 of GitHub Free's shared $12 included monthly compute. No Actions artifacts, caches, LFS, D1, R2, Containers or paid Worker subscriptions are required. Keep paid Actions use blocked at the account level. When a resource limit stops an update, the last deployed timetable remains available. Network Rail publication, GitHub scheduling and user traffic can vary. The timetable status endpoint gives the current publication time.

The worker authenticates app and timetable requests. The Workers Free allowance is 100,000 dynamic requests per account per day. Other Workers and traffic to staging share this allowance. Static asset limits are 20,000 files per version and 25 MiB per file. The packer rejects oversized candidates. No free plan guarantees service under unlimited traffic.

## Enable staging

Use the original real Network Rail database to bootstrap. Run python3 rail/pack.py /path/to/schedule.sqlite public, then a Wrangler dry run from this directory. After confirming free usage, publish the isolated staging Worker using Wrangler 4.160.0 and verify the actual returned URL and the signed-in application. The local login file is held outside version control. To change the login, set STAGING_AUTH_SHA256 to the SHA-256 digest of the complete Basic Authorization header for the new high-entropy credentials.

Set repository variables STAGING_URL and CLOUDFLARE_ACCOUNT_ID. Store NR_USERNAME, NR_PASSWORD and CLOUDFLARE_API_TOKEN in encrypted repository Actions secrets. Use a Cloudflare token with Workers Scripts Edit limited to the staging account. The workflow only needs Workers deployments, without zone routes or storage permissions. On shared accounts this Cloudflare permission can edit other Workers, so restrict write access to the private repository. Set FREE_UPDATES_ENABLED to yes only after the billing stop and remaining included usage have been checked. Test a workflow dispatch, check the active publication via /api/journey-rail/status and test Rail and Sooty. An unchanged publication exits without deployment. A later publication is required to exercise promotion end to end.

## Recovery

An incomplete download, failed validation, failed search equivalence check or failed version upload leaves the previous deployment active. The promotion step captures the current staging version, promotes only a newer verified snapshot and checks the deployed publication. If that check fails and the candidate still owns all traffic, it requests a rollback. For manual recovery remove FREE_UPDATES_ENABLED and restore the previous verified version from the staging Worker's Deployments tab. Monitor failed Actions jobs, including timeouts or interruptions during promotion. Cloudflare deployment history supports short-term recovery. The separate offline staging ZIP includes the application and the baseline timetable boards. The in-app export contains editable sources. Use the external offline ZIP or regenerate boards before deploying an in-app export. Older unmodified Journey 67 and Journey 68 recovery files remain available.

Sources: https://docs.github.com/en/billing/concepts/product-billing/github-actions and https://developers.cloudflare.com/workers/platform/limits/