The story this week is that we added a Base Environment selector for PR Environments at the Project level. 

The meta-story is that there was a bunch of confusion around how to spin-up ephemeral environments on the fly so we hope this helps you better deliver incremental improvements to your applications. 

The meta-meta story is that this improvement is part of a series of lifecycle management improvements we’re making this quarter, with more are on the way.

The meta-meta-meta story is that, like, what is life 

 but a series of lifecycle managem— just kidding. 

The new Base Environment selector in Project-level settings

 we mentioned that we’re working on bringing the base environment setting from service-level settings to project-level settings since having to edit the base environment for each service independently was a huge pain — especially for those of you working in a monorepo.

 selector to Project settings. When enabled, submitting a PR will fork the base environment to the PR environment with all environment variables copied over.

This is useful if you have different variables for Staging and Production, such as Stripe Test keys and Stripe Live keys. The PR environment will hold all the configuration of your base environment and will be forked for all PR environments for all repos and branches. 

We hope this eases the confusion felt by many of you when wondering why your change to the base environment setting for Service A did not also change the base environment for Service B. 

Next up, we’re continuing our work to improve lifecycle management. In particular, merging and forking environments will soon be a first-class feature. 

We migrated our monorepo to vanilla Tailwind and reduced dev build times by 2x

We completed a large frontend migration that ripped out Twin and replaced it with vanilla Tailwind across 400+ components, which reduced our dev build times by 2x and reduced our dev environment cold starts by 20x+. 

We ran into a bunch of interesting problems during this migration — if you’re curious why and how we did this migration, Railway Engineer Alberto 

We’ve made a number of improvements to our internal ticketing system to better prioritize requests from Developer and Teams users. This means improved support escalation, better response times, and overall a better experience for you as a paying Railway user.

We fixed a bug that allowed some users to deploy to deleted environments

We fixed a bug that affected unverified users when trying to create tokens

We fixed a bug that showed an environment selector in Project Settings

We fixed a confusing SQL placeholder in Postgres

https://res.cloudinary.com/railway/image/upload/v1683321872/og-images/pr-envs-in-project_uotr8c.png

PR Environments at the Project Level, Migration to Tailwind Complete, Team Support

Changelog #0132