12 days ago
Hello, we are evaluating a sandboxed image-decoding worker on the Hobby plan. In an isolated synthetic test service (Debian bookworm, Python 3.11.16, bubblewrap 0.8.0-2+deb12u1, uid 0), CPU, address-space and wall-time limits worked, but bubblewrap exited with: "bwrap: Creating new namespace failed: Permission denied". The command requested user, PID, network, IPC and UTS namespaces plus a restricted mount namespace. No customer files or application credentials were used, and the one-shot deployment has been removed.
Can you confirm whether nested user/mount/network namespaces are supported in standard Railway containers on Hobby? Is there a documented, supported configuration for bubblewrap or another per-process sandbox that restricts filesystem access and denies network access to an image decoder? If these capabilities are unavailable, is there another Railway execution product suitable for this workload on Hobby, and how does its billing differ?
We need platform capability guidance only. Please do not change services, permissions, plans or billing. Please link the relevant documentation and distinguish supported behavior from a suggested workaround. Thank you.
1 Replies
12 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 12 days ago
12 days ago
Your observed error proves that the requested combination of namespace operations was denied in that standard service. It does not identify which of user, mount, PID, network, IPC or UTS namespace creation failed, nor establish a platform-wide policy. I could not find a Railway guarantee for nested namespaces, bubblewrap, or a customer-configurable privileged/seccomp profile in standard Hobby services. I would not rely on a different bwrap flag combination for this untrusted decoder without Railway confirming a supported configuration; dropping --unshare-net would also drop your no-network requirement.
Railway documents a separate execution primitive: Sandboxes are isolated Linux VMs available on every plan, including Hobby. You can create one per job and destroy it afterwards. But the networking section says every Sandbox has outbound internet access. The default ISOLATED mode blocks access to the environment's private network; PRIVATE adds that access. Neither mode denies internet egress. So a Sandbox provides a VM boundary, but by itself does not satisfy your network-denied decoder requirement. I did not find a documented outbound-deny option for Sandboxes.
For cost, Railway's plan pricing lists Sandbox VM usage at $50/GB-month of RAM and $50/vCPU-month of CPU, versus $10/GB-month and $20/vCPU-month for standard containers; egress is $0.05/GB in both cases. VM use is metered per second and draws from Hobby's same $5/month included resource usage. Destroying the VM stops further compute usage.
A Railway team member would need to confirm whether standard Hobby containers support any nested user/mount/network namespace configuration and whether any Railway product offers a supported outbound-deny mode. Based on the published Sandbox networking contract, I would keep the decoder on a host where you can enforce both filesystem and network isolation, instead of weakening either requirement. No service, plan, or permission change is needed to evaluate this.