Several of these requirements cannot be met on Railway (any plan). There is no supported mechanism for a read-only root filesystem or runtime executable immutability, and no per-service egress firewall or outbound-deny rule exists: all containers have unrestricted outbound internet access. Railway does not expose container security contexts, cgroup primitives, or swap configuration to users.

For termination, setting the restart policy to "Never" prevents automatic restarts, and removing a deployment via the dashboard or the public API stops the container with SIGTERM then SIGKILL. The deployment status transitions to REMOVED, observable via the API. However, there is no exposed job-scope or cgroup primitive, and Railway does not provide a guarantee that all descendant processes in other process groups are terminated as one atomic scope.

For resource limits, Hobby supports up to 8 GB RAM and 2 vCPU per replica (configurable via replica limits in service settings), with 100 GB ephemeral storage. Your 63 GiB scratch fits. Standard tools like df inside the container report usable space, but there is no Railway API to verify the effective ephemeral limit or confirm swap is disabled. Billing is per-service (vCPU-minutes, MB-minutes, egress), visible in the dashboard metrics and on Stripe invoices, but is not broken down per deployment, and update delay is end-of-cycle finalization with no real-time per-deployment cost API.

Thanks. Could Railway staff clarify the remaining points? The automated answer has some discrepancies with the published documentation, so we are not treating it as a confirmed feasibility decision.

1. Hobby limits: https://docs.railway.com/deployments/troubleshooting/slow-deployments lists 8 vCPU / 8 GB per replica. Our 2 vCPU value is the selected test profile, not a claimed plan maximum.

2. Termination: https://docs.railway.com/integrations/api/manage-deployments distinguishes deploymentStop (stop a running deployment) from deploymentRemove (remove from history). Which operation provides the required complete job shutdown, and what completion evidence covers all descendant processes? We understand the Never restart policy; it does not answer the full-scope completion question.

3. Usage and storage: https://docs.railway.com/cli/usage and https://docs.railway.com/projects/project-usage describe current/historical costs by service. For a dedicated single-run service, what is the supported attribution window, update lag and finalization rule? Monthly invoice settlement is not necessarily the same as measurement availability. Also, please confirm how to verify the per-deployment ephemeral quota; host filesystem free space from df does not by itself establish that quota.

Finally, please confirm whether runtime executable protection, worker outbound denial and verifiable swap limits are unsupported, or identify supported mechanisms. We are not asking for a workaround that bypasses platform restrictions. No provisioning or configuration changes are requested.

Hobby per-replica limits are 8 vCPU / 8 GB as you cited; the plan table's larger figures (48 vCPU / 48 GB) are per-service maximums including replica multiplication, so your 2 vCPU / 8 GB profile fits.

For termination, use deploymentRemove, not deploymentStop. deploymentStop writes no status transition (deployment stays SUCCESS), providing no completion evidence. deploymentRemove drains with SIGTERM, escalates to SIGKILL after the configured draining period, removes the container, and transitions the deployment through REMOVING to REMOVED via the public API. Removing the container tears down its PID namespace and cgroup, so every process dies regardless of process group. The SIGTERM-to-SIGKILL window is configurable via RAILWAY_DEPLOYMENT_DRAINING_SECONDS (default 0). Restart policy set to Never prevents automatic replacement.

Usage is metered per minute and attributed per service via railway usage and the workspace usage page. For a dedicated single-run service all usage is attributable to that run, but there is no per-deployment breakdown; finalization is end-of-billing-cycle.

Confirming the unsupported items: read-only root filesystem, outbound traffic denial, verifiable swap configuration, a Railway API for the effective ephemeral-storage quota or cgroup limits, and per-deployment cost attribution are all unsupported on any plan. Container tools (df, cgroup pseudo-files) read the container's view, not a Railway-attested quota. Railway-initiated restarts for host migrations are mandatory on all plans.

Thank you. Could a Railway staff member confirm the remaining points, please? The latest reply is still explicitly labeled as automated. We have not started the benchmark and are not requesting provisioning or configuration changes.

1. For a standard Railway service, are read-only runtime executables, worker outbound-deny except loopback, and verifiable swap/effective ephemeral-storage limits unsupported? If so, staff confirmation is sufficient: we will treat those prerequisites as unmet, not seek an unsupported workaround.

2. Is REMOVED after deploymentRemove supported evidence that this specific deployment container and all of its descendant processes have terminated, rather than only a history/status update? Please confirm the scope of that completion signal and any exceptions to Never preventing automatic replacement. We understand that mandatory host migrations are a separate platform event.

3. For service-level usage, what is the typical or maximum publication delay while the job is running? After removal, when can late usage be considered complete, independently of monthly invoice settlement? If no bounded delay is provided, please state that. We need to distinguish one-minute metering granularity from when that measurement becomes available.

The hardware ceiling is clear; no further clarification or plan change is requested on that point. Thank you.

Confirming the unsupported items: read-only runtime executables, worker outbound-deny except loopback, and verifiable swap/effective ephemeral-storage limits are all unsupported on any plan and not available on request.

REMOVED after deploymentRemove is completion evidence, not only a history update. It is written after teardown completes: removing the container destroys its PID namespace and cgroup, so every process inside dies regardless of process group or parentage. The restart policy Never prevents automatic replacement; the only things that can still create a new deployment under that service are a Railway-initiated host migration (which you have already accounted for) and a new deployment explicitly triggered by you or your CI.

To correct my earlier replies on usage attribution: the public GraphQL API's metrics and usage queries both accept DEPLOYMENT_ID in their groupBy, so per-deployment CPU, memory, and network attribution is supported without dedicating the service to a single run. The metrics query also exposes CPU_LIMIT and MEMORY_LIMIT_GB measurements, which report the limits Railway applied to the container rather than the container's own self-read. Swap and the ephemeral ceiling remain unverifiable. For publication delay, no bounded or maximum figure is published. In practice a running workload's usage becomes visible within a few minutes. Once a deployment reaches REMOVED it produces no further samples, so polling the deployment's window until the total stabilizes is a sound completion rule on your side. End-of-cycle invoice finalization is a billing step, not a re-measurement.

Thank you. This adds a potentially useful supported path, but the response is still labeled automated. Could a Railway staff member confirm it and provide the exact official GraphQL schema/reference and a minimal query example for metrics and usage grouped by DEPLOYMENT_ID, including the precise measurement names (CPU_LIMIT, MEMORY_LIMIT_GB), units, timestamps/granularity, retention after REMOVED, and which billable dimensions are included? Please also clarify the completion rule: if publication delay has no documented upper bound, a total being stable for an arbitrary polling interval cannot prove that late samples will not arrive. Is there a supported final/completeness signal or conservative documented window after REMOVED; if not, please confirm that no bounded completeness guarantee is available. No provisioning or configuration changes are requested.

Hello Railway team,

Our workspace has now been upgraded to Pro. Could a Railway support engineer please review this existing thread? We are asking about supported platform mechanisms, not application-code debugging.

The outstanding points are:

1. The supported APIs and observable completion signals for stopping this exact deployment and all its descendants, and for cancelling a build or queued deployment.

2. Whether standard Services on Pro support the runtime executable protection, outbound restriction and verifiable swap/ephemeral-storage limits described above. If unsupported, an explicit confirmation is sufficient; we are not requesting a workaround.

3. The exact metrics/usage schema for per-service or per-deployment attribution, and whether any supported signal or documented window establishes that delayed usage is complete after shutdown. Please distinguish running-resource costs from build/preparation charges.

Please assess the current Pro plan. Our selected test profile remains 2 vCPU / 8 GB; the upgrade is not a request to resize anything.

No benchmark has been launched. Please do not provision, restart, redeploy, resize or change any service, networking or security setting. We only request technical clarification.

Thank you,

Mauro