What's stopping you from choosing Railway at work?

Are you already using Railway for your personal projects but really wish you could use it at work?

Perhaps there's a specific requirement your company has or a feature that Railway doesn't have yet that's holding you back? Whatever it is, we'd love to know about it.

You can share your thoughts down below ↓

6 Replies

Railway
BOT

8 months ago


rjbathgate
PRO

8 months ago

A firewall!fire emoji

I am using Railway for work already, but we would LOVE some firewall ability.

We need our MySQL container to be accessible outside our railway .internal network for few known services so we have a TCP proxy set up.

Yes, the TCP proxy and random port make it hard to 'guess', and the root password is secure (and not used anywhere), but there is still a small risk of having MySQL open to public.

I thought about disabling the root user entirely, but figured this would not persist on redeployment of the container, so not a long-term solution (and also has the potential to lock me out!)

So, we would love to be able to lock down public access to our MySQL container (or indeed any container) to an IP whitelist (and block all others).

Please? sunglasses emoji


rjbathgate

A firewall!I am using Railway for work already, but we would LOVE some firewall ability.We need our MySQL container to be accessible outside our railway .internal network for few known services so we have a TCP proxy set up.Yes, the TCP proxy and random port make it hard to 'guess', and the root password is secure (and not used anywhere), but there is still a small risk of having MySQL open to public.I thought about disabling the root user entirely, but figured this would not persist on redeployment of the container, so not a long-term solution (and also has the potential to lock me out!)So, we would love to be able to lock down public access to our MySQL container (or indeed any container) to an IP whitelist (and block all others).Please?

8 months ago

Hello,

While we don't have a native firewall, you could use Tailscale, and I think this template will help you achieve exactly what you want to do.

https://railway.com/deploy/tailscale-forwarder

Tailscale Forwarder is a TCP proxy that allows you to connect through a Tailscale machine to the configured target address and port pair. This enables secure access to Railway services that are not accessible from the internet, effectively creating a private network tunnel for your infrastructure.


rjbathgate
PRO

8 months ago

Yeah, I have set up tailscale as a temporary solution, but it's a bit of a workaround (and not always a working solution, for example if we need to give access to an end user who is not part of our tailscale network) and a native firewall would be much better (and this thread is about things we want sunglasses emoji)


Anonymous
PRO

8 months ago

Sorry for the wall of text, but I figured the timing for this thread was serendipitous. I've spent the last couple of days evaluating whether I can switch over to Railway from k8s (I have believed, and still do, that Railway is a promising provider), but I've run into some big issues that have led me to believe I can't switch yet. Here are some specific suggestions I have to make it easier to move more mature infrastructure over to Railway:

  • Make Docker Images a first-class deployment option

    • Docker Images should also be able to support different tags in different environments.

    • It should be easier to set resource limits through config-as-code for a service running Docker. I haven't seen a way to do this.

    • I haven't seen how to define startup/readiness/liveness probes for docker. As long as a service doesn't crash, Railway seems to think it is working fine.

    • The only way I found to deploy a docker image is through the Terraform provider/API. This means that all of the .json configuration you make available to services built on Railway are not available to services built elsewhere.

    • Supporting arbitrary private registries using username/password auth would be nice. In my naive opinion, if you can docker login ... to a registry, that registry should also be a potential source.

  • Make First-Party Terraform/OpenTofu a priority

    • On security: when you're using the terraform provider to save potentially sensitive variables, having it be controlled by Railway would increase the perception of security, even if the current state is 100% secure (as I suspect it is).

    • Bringing Terraform in-house would also allow for the provider to be kept up-to-date with all the newest Railway features, rather than the community maintaining just the primary features they personally use.

    • As an example of what peer companies are doing with Terraform, Doppler itself has an excellent Terraform provider. You don't need to be Google or AWS, but a little goes a long way.

  • Observability

    • People switching over likely already have an existing o11y platform. Exporting metrics and logs, even if you bill transferred data at egress rates, would be welcome. I don't want to have to juggle dashboards on multiple platforms just because I use distributed tracing or have servers running elsewhere.

    • Just quickly clicking around the project o11y view, it would be good to have:

      • Aggregations (sum/mean/max/min) to see what my services are doing. (I.e. how much CPU & memory am I consuming across all of my services in the env?)

      • The ability to compare different environments and projects, potentially to have a central place to view all projects instead of just one.

  • Railway should publicly offer a SLO for system reliability. Even if it is not a contractual obligation or does not have any financial backing, having a public number that says 'this is what we target' would be a good addition for people comparing you with other vendors. Even if it is historical over the last x many months, that would be a good point of comparison.

In short, with all other providers I use, I have IaC set up such that no individual detail is manually entered; everything is defined a certain way and then config drift is addressed by further terraform apply actions. With the Railway model, IaC-deployed resources are not as deterministic.

Also, while the nixpack/railpack focus is good for people getting started, it does not work as well for orgs that have mature CICD systems. I agree that it's good to not need to worry about DevOps at the beginning, but once you have it you don't want to lose it (at least in my opinion).

Ultimately, I will still read every changelog that comes my way, and I hope that someday I'll be able to migrate some, if not all, of my compute over to you. What you're building with Metal is truly awesome. But for now, sadly, I cannot justify switching.


superslowsloth
HOBBY

8 months ago

We’d love to use railway more at work! Right now it is for PoCs. We’re only missing horizontal scaling based on traffic ram cpu and rabbitmq queue length. 

Adding repo from org experience could be better as well. 

Cheers!


Loading...