We are assessing a single isolated PostgreSQL benchmark on Railway Hobby. Please do not provision or change anything. We need supported mechanisms; please identify any requirement that cannot be met on Hobby. The proposed job uses one replica, 2 vCPU, exactly 8,000,000,000 bytes of memory, swap disabled, an ephemeral PostgreSQL 16 database, no automatic retries and a maximum of 24 hours including setup and cleanup. These are maximum limits, not a request for dedicated CPU performance. A restart or host migration would invalidate the run; we are not asking to opt out of mandatory migrations. Could you clarify these three areas and point to the supported configuration/API and observable evidence for each? If a requirement is unsupported, please say so. 1. Execution identity, executable protection and worker network isolation. Can an external controller bind the exact running instance/deployment to its image and protect the executable files from changes for the duration of the job (read-only executable mount/root or an equivalent supported mechanism)? A reported image digest alone would not prove runtime file immutability. Can outbound traffic from the benchmark worker be denied except for loopback, while keeping a separate authenticated control/evidence channel? We must not rely merely on the absence of public ingress or on not storing provider keys. 2. Bounded termination of only this job. What supported operation lets an external controller stop this exact job and all of its descendants as one scope, including processes in other process groups? What can the controller observe to confirm that the entire scope is gone and that it was not automatically restarted/replaced? Does removing a deployment provide these guarantees? The termination operation must be scoped to this job, not the workspace. If a narrower job/cgroup primitive exists, please identify it and whether it is available to Hobby services. 3. Effective resource limits and attributable cost. Can the controller verify the effective CPU/memory/swap limits and actual available ephemeral storage for that job? We need 63 GiB total scratch, of which 28 GiB is evidence, not an additional persistent volume. Services docs state 100 GB ephemeral storage for paid plans; what is the supported way to verify the applicable limit and usable space, rather than the backing host's free space? What usage/cost API or metrics can attribute BEFORE/AFTER usage to this exact run without mixing usage from other services? Please specify granularity, update delay, finalization and any additional controller/storage/export costs. If an external controller is necessary, please identify the supported interfaces and scope required. This is a feasibility inquiry only, not a request to provision resources or change configuration.

Hobby service feasibility for an isolated, bounded PostgreSQL benchmark

electrodrive-oficial

HOBBYOP

5 hours ago

We are assessing a single isolated PostgreSQL benchmark on Railway Hobby. Please do not provision or change anything. We need supported mechanisms; please identify any requirement that cannot be met on Hobby.

The proposed job uses one replica, 2 vCPU, exactly 8,000,000,000 bytes of memory, swap disabled, an ephemeral PostgreSQL 16 database, no automatic retries and a maximum of 24 hours including setup and cleanup. These are maximum limits, not a request for dedicated CPU performance. A restart or host migration would invalidate the run; we are not asking to opt out of mandatory migrations.

Could you clarify these three areas and point to the supported configuration/API and observable evidence for each? If a requirement is unsupported, please say so.

Execution identity, executable protection and worker network isolation.

Can an external controller bind the exact running instance/deployment to its image and protect the executable files from changes for the duration of the job (read-only executable mount/root or an equivalent supported mechanism)? A reported image digest alone would not prove runtime file immutability.

Can outbound traffic from the benchmark worker be denied except for loopback, while keeping a separate authenticated control/evidence channel? We must not rely merely on the absence of public ingress or on not storing provider keys.

Bounded termination of only this job.

What supported operation lets an external controller stop this exact job and all of its descendants as one scope, including processes in other process groups? What can the controller observe to confirm that the entire scope is gone and that it was not automatically restarted/replaced? Does removing a deployment provide these guarantees?

The termination operation must be scoped to this job, not the workspace. If a narrower job/cgroup primitive exists, please identify it and whether it is available to Hobby services.

Effective resource limits and attributable cost.

Can the controller verify the effective CPU/memory/swap limits and actual available ephemeral storage for that job? We need 63 GiB total scratch, of which 28 GiB is evidence, not an additional persistent volume. Services docs state 100 GB ephemeral storage for paid plans; what is the supported way to verify the applicable limit and usable space, rather than the backing host's free space?

What usage/cost API or metrics can attribute BEFORE/AFTER usage to this exact run without mixing usage from other services? Please specify granularity, update delay, finalization and any additional controller/storage/export costs.

If an external controller is necessary, please identify the supported interfaces and scope required. This is a feasibility inquiry only, not a request to provision resources or change configuration.

Awaiting User Response

3 Replies

Railway

BOT

5 hours ago

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.

Status changed to Awaiting User Response Railway • about 5 hours ago

Railway

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](https://docs.railway.com/integrations/api/manage-deployments) 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.

electrodrive-oficial

HOBBYOP

5 hours ago

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.

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.
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.
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.

Status changed to Awaiting Railway Response Railway • about 5 hours ago

Railway

BOT

5 hours ago

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.

Status changed to Awaiting User Response Railway • about 5 hours ago

Welcome!