Hosting & Infrastructure
How our Railway-hosted products are deployed, isolated, and operated — and how that differs from the Bedrock AWS platform.
Draft — verify before publishing. Confirm every infrastructure detail below against the actual Railway configuration for each product before this page goes live.
Our commercial SaaS products (vCISO, Praevio, RailCompliant) are deployed on Railway, a managed platform that handles the underlying compute, networking, and TLS termination. RailCompliant additionally sits behind Cloudflare, which provides network delivery, TLS, and denial-of-service protection in front of Railway. Bedrock GRC is hosted by Foxx Cyber on Railway as well; organizations that need it on their own infrastructure can run it themselves, on request. Each product is a container image built by the same CI pipeline described in CI Guardrails, scanned before release, and promoted to a pinned image tag that the platform runs. Bedrock GRC passes the same gates, but Railway builds its image from the reviewed source rather than running a promoted tag; the tagged images are what self-hosted installs run.
Deployment model
- Container images, built and scanned in CI. Images are produced by the
project pipeline, scanned for
HIGH/CRITICALvulnerabilities, and only then promoted to the tag the environment runs. The platform runs a pinned image tag rather than auto-pullinglatest, and only images that passed the gates are deployed. For products that deploy continuously (RailCompliant, for example), a green main-branch pipeline pins the service to the image it just built and scanned. - Managed TLS. Transport is encrypted end to end; the platform terminates TLS at its edge and the application is reached over HTTPS.
- Managed Postgres. Persistent data lives in a managed PostgreSQL database provisioned per product, reachable only by that product's service.
- Object storage for files. Products that keep uploaded files (RailCompliant's photos, documents and attachments, and Bedrock GRC's documents and evidence, which the application encrypts before they leave it) store them in the platform's S3-compatible object storage, not in the container.
Isolation
- Per-product services. Each product runs as its own service with its own database; products do not share application runtimes or data stores.
- In-application tenant isolation. Within a product, tenant separation is enforced in the application layer under the tenant-scoping invariant — every scoped query carries a server-derived tenant identifier that is never accepted from the client.
- Secrets in the platform, not the image. Configuration and secrets are injected as environment variables at runtime, or, for third-party keys an operator enters in an admin console (RailCompliant's Stripe and email keys), stored in the database encrypted with AES-256-GCM. Either way they are not baked into the image and are not committed to source control.
How this differs from the Bedrock platform
| Railway-hosted products | Bedrock platform | |
|---|---|---|
| Compute | Railway managed platform | Dedicated AWS infrastructure |
| Data boundary | Per-product managed Postgres | Defined CUI boundary on AWS |
| Air-gapped component | None | C3PAO assessor application |
| Governing document | This section (commercial SaaS practices) | Public Bedrock SSP |
If you need a formal, control-by-control security package for a Railway-hosted product — for a vendor security review, say — reach out through support. What's published here is a plain-language summary, not a compliance attestation.