This summer: your code, your deployments, all day and night long on WCLG Railway FM.

 What’s up everybody! We got a special Changelog for you today. We have usual classics from your usual engineers, and future classics from new engineers. 

And let me tell you, these features are the real deal. We’re talking built-in network logs, 

, and UI organization for larger parties, I mean, companies.

Anyway, let’s kick off Changelog #0200 (!) with something extra special. 

) about the benefits of migrating to the new proxy and it’s not because we just want you on a new proxy.

It’s because from Day 1, we’ve wanted to help developers avoid futzing around with external monitoring tools just to see how their application behaves. 

Now you can see the traffic your service receives 

HTTP Logs is a new feature available at the service level

With this release, you can now see HTTP status code logs for requests on the deployment details page, including response time and the path and method used. 

Plus, if there were any errors encountered when trying to reach your application, you can now view exactly what error our edge encountered — protocol mismatches, timeouts, etc. are all now visible when expanding the log with a single click.

This is a massive step to have observability baked right into the platform helping you (and Railway) dig into networking issues no matter how complicated.

Yes, we have a caller from the audience. Y

ea, you want it in the Observability pane? Filtering? We’ll you’re just going to have to stay tuned for another Changelog.

It’s the end of brat summer. (We just learned about that, sorry.) … And it’s nearly the end of intern season. (We always knew about that.) With that, we know that customers sometimes have seasonal help with their codebases large and small.

While the compliance team is engaging with Terms of Service and RBAC controls

, the product team, namely Paulo, felt fit to beef up our controls on the platform. 

By default, for users who aren’t connected to Railway with their GitHubs, we will hold the deploy and prompt that you approve or deny the deployment. 

This should be helpful for when you want the intern’s code to go into 

 but don’t want it to cause the hypothetical water main to break.

If the user isn’t a part of your project or team on Railway, we won’t prevent a deployment outright — we will queue the deployment for someone trusted within your company to waive the deployment through.

Deployment approvals are new on the platform

This feature came out of a request from companies and agencies alike to:

Ensure that only current employees have access to deploy repos they have access to

Ensure manual control over the deployment pipeline

Make sure that the Railway GitHub app, only deploys if you are in a Railway Team or Project scope. Before, the GH app wouldn’t care who pushed a commit … which is not great if you want to do RBAC

We understand that it doesn’t make total sense for companies to pay for a seat to floating contributors. For consultancies and agencies who work with outside contractors or external clients, you can add your collaborators to the project at no cost via the Project Settings.

While we were at it: We also added an additional Webhook event and another email type for approvals.

“But webhooks and emails are too noisy!”

We’ll see you for another Changelog for that one.

is turning it up to eleven as of late and a new drop from him means we should all tune in and listen.

We now have a tutorial that will guide you to 

 ing it back with us in the old days, Railway would expose everything publicly. But sometimes you don’t want your traffic to be public. And that means connecting to those services was a bit challenging and the bouncer would never let you in.

This new guide, if followed, allows the user to tunnel into the private network via Tailscale. (And yes, we’re biased, we like their VPN.) It’s then possible to connect to anything in the project’s private network from the comfort of your own computer without ever having to connect to the service's public host and port. 

Just like your computer was just another service in the project.

We’ve introduced new list sorting for projects in the dashboard

Four items in the Changelog? Get used to it!

 project catalogs shouldn’t feel like a cluttered Foobar2000 setup. As such, JR decided to turn back the clock and do some spring cleaning.

We have now added new filters so you can filter by 

 recent activity, creation, or from A-Z. 

Added a list view (displayed in the screenshot)

Made mobile suck less (JR’s words exactly)

We hope it makes moving around the platform a little bit more easier as you and your team continue to deploy the night away.

We are pleased to announce that Chandrika joins us on the journey as our new Support Engineer!

We fixed a bug where the service pane will freeze if you closed the deployment details pane

We fixed a bug with Deployment Approvals not “Approving” when you “Approved” them

We fixed the formatting of Help Station emails

We have now pinned all MySQL, Mongo, Redis, and Postgres versions so DB redeployments shouldn’t cause an upgrade error

We fixed a very rare issue where Railway would deploy a old 

We now notify you in the Template Deploy 

 if a template requires a Pro plan feature

We now use Docker BuildKit for everything — look at those builds go!

 UI will no longer cause an outage, hopefully, ever

[Deprecated] We removed the Heroku to template migration flow

https://res.cloudinary.com/railway/image/upload/v1724453049/changelog-200_zsdiox.png

HTTP Logs, Deployment Approvals, Tailscale Guide, Dashboard UI Improvements