Deploy and Host Hoverfly API Simulation on Railway

Capture and simulate API behavior with authenticated administration.

Draft status: Configuration and upstream documentation reviewed. Container startup, Railway application workflows, restart behavior, backup restoration and costs remain unverified.

About Hosting

Capture and simulate API behavior with authenticated administration.

Service	Role	Persistent path
`app`	Private application or dependency	`None`
`hoverfly`	Public owner gateway	`None`

Why Deploy

Run this application in your own Railway project, with explicit configuration and storage under your control.

Common Use Cases

Capture and simulate API behavior with authenticated administration.

Dependencies for Hoverfly API Simulation

Deployment Dependencies

The application images are pinned by registry digest. Database services, when included, stay on the private network. One replica is supported for each volume-backed service.

First use

Open the hoverfly service's HTTPS domain. Sign in to the owner gateway with username admin and its generated ACCESS_PASSWORD. Complete the application's own setup afterward.

API calls must also send X-Template-Key with that owner password. The gateway forwards native Bearer tokens, strips Basic Authorization, and limits requests to 32 MiB. Browser sessions receive a secure owner cookie. Native clients, webhooks and public sharing require specific compatibility checks before use. Gateway /healthz only checks the proxy, not application readiness.

Enter the owner gateway, then use the native Hoverfly account owner and HoverflyAdminPass. Import a simulation in the UI/API. Applications in this project use the app private domain on port 8500 with Hoverfly proxy authentication.

Scope and limitations

Simulations, journal entries and runtime user changes are in memory. Keep simulation JSON in source control and reimport after restart.
The proxy listener is private. Capturing HTTPS requires clients to trust Hoverfly’s generated certificate, configured by the operator.
Automated administration requests need X-Template-Key plus the native Hoverfly Bearer token.

Acceptance checks before use

Import a known simulation and call it through the private authenticated proxy.
Verify the admin API requires native authentication and export the simulation before restart.
Confirm generated credentials are distinct on a second fresh deployment.
Back up every listed persistent path and database, then restore into a separate test project.
Measure Railway usage with representative data and workload before estimating operating costs.

Backups and upgrades

Back up databases, file volumes, encryption keys and configuration together. Keep a copy outside the running project. Review upstream migration notes before changing a digest; rollback can require restoring a compatible database and files, not just selecting an older image.

Sources and selection evidence

Upstream documentation: Native administration JWT and proxy Basic authentication.
Upstream documentation: Exact mixed-case authentication and port environment variable names.
Upstream documentation: Creates an admin from HoverflyAdmin/HoverflyAdminPass when auth is enabled; default storage is memory.
Upstream documentation: Image binds all interfaces with /bin/hoverfly; admin 8888 and proxy 8500.
Upstream project

Product and alias searches found no matching public Railway listing during this research. This is a bounded search result; private, unindexed or differently named listings may exist. It is not evidence of demand or revenue.

Upstream software retains its own license and edition restrictions. This deployment draft does not imply upstream endorsement.