2 months ago
https://docs.railway.com/sandboxes#reaching-a-port-in-a-sandbox
Does this imply I can't reach, say, a Next.js dev server running in a private sandbox? Would I be able to create some sort of traffic orchestration service that forwards traffic to a sandbox if said sandbox was "PRIVATE" instead of "ISOLATED"?
For context, I'm building a Loveable-like service and sandboxes seem to be a good primitive for shortlived app dev environments.
4 Replies
2 months ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 2 months ago
2 months ago
yes, PRIVATE does what you want. from the docs: "the sandbox joins the environment's private network and keeps outbound internet access. it can reach other services over private networking... and they can reach it." so a proxy service sitting in the same environment can forward traffic into a PRIVATE sandbox. the "no public endpoint" line only means railway won't hand the sandbox its own domain or tcp proxy, not that nothing can reach it internally.
the thing i'd watch for with your use case is the idle timeout. it only counts your interactions with the sandbox, exec or ssh. a process running inside doesn't keep it alive, and neither will traffic you proxy in. so a next.js dev server could be actively serving requests through your orchestrator and railway would still tear the sandbox down once the timer runs out. 30 min default on hobby/pro, 120 max, but only 5 min on trial/free.
if you go this route you'd want your orchestrator to fire a cheap exec against the sandbox periodically as a keepalive, otherwise short-lived envs will die under active use.
one gap: docs don't say how you actually address a sandbox on the private network, there's no documented .railway.internal name for them like services get. worth asking staff how to resolve it before you build around it.
manuproject
yes, PRIVATE does what you want. from the docs: "the sandbox joins the environment's private network and keeps outbound internet access. it can reach other services over private networking... and they can reach it." so a proxy service sitting in the same environment can forward traffic into a PRIVATE sandbox. the "no public endpoint" line only means railway won't hand the sandbox its own domain or tcp proxy, not that nothing can reach it internally. the thing i'd watch for with your use case is the idle timeout. it only counts your interactions with the sandbox, exec or ssh. a process running inside doesn't keep it alive, and neither will traffic you proxy in. so a next.js dev server could be actively serving requests through your orchestrator and railway would still tear the sandbox down once the timer runs out. 30 min default on hobby/pro, 120 max, but only 5 min on trial/free. if you go this route you'd want your orchestrator to fire a cheap exec against the sandbox periodically as a keepalive, otherwise short-lived envs will die under active use. one gap: docs don't say how you actually address a sandbox on the private network, there's no documented .railway.internal name for them like services get. worth asking staff how to resolve it before you build around it. https://docs.railway.com/sandboxes#networking
2 months ago
@manuproject If the bounty is worth it, can you do a cheap poc with a web server returning hello world in a sandbox that is reachable from an orchestration service? If you're unable, I'll wait for staff to chime in on that last piece and then accept your solution!
ryanhaticus
@manuproject If the bounty is worth it, can you do a cheap poc with a web server returning hello world in a sandbox that is reachable from an orchestration service? If you're unable, I'll wait for staff to chime in on that last piece and then accept your solution!
2 months ago
did the poc, it works. sandbox on --private-network, hello world server inside it, reached from a service in the same environment.
what i ran:
railway sandbox create --private-network
railway sandbox exec -- cat /proc/net/if_inet6
that gave the sandbox's private address on the fd12:... line (base image has no ip command so read it from /proc). formatted out it was fd12:632d:7c8b:1:d000:1ba:fa2e:7917
then started the server, bound to :: not localhost:
railway sandbox exec --detach -- bash -c "mkdir -p /tmp/poc && echo 'hello world' > /tmp/poc/index.html && cd /tmp/poc && python3 -m http.server 3000 --bind ::"
then from the Console of a normal service in the same environment:
node -e "fetch('http://[fd12:632d:7c8b:1:d000:1ba:fa2e:7917]:3000').then(r=>r.text()).then(console.log)"
returned: hello world
three things that'll bite you building on this:
private networking is ipv6, so the dev server has to bind :: — localhost or 0.0.0.0 alone won't be reachable
there's no dns name for a sandbox, nothing like .railway.internal. you read the address out of the sandbox after it boots and hand it to your orchestrator, so that's a step in your provisioning flow
base image is bare debian, no python/curl/ip. worth preinstalling what you need in a template or you pay the apt-get cost every boot
and the idle timeout still applies, proxied traffic doesn't count as interaction, so you'll want a keepalive exec or the envs die mid-session.
Status changed to Solved 0x5b62656e5d • about 2 months ago