--- title: "PR Environments at the Project Level, Migration to Tailwind Complete, Team Support" date: 2023-05-05T15:00:00.000+00:00 number: 0132 url: https://railway.com/changelog/2023-05-05-pr-environments-project-level --- # PR Environments at the Project Level, Migration to Tailwind Complete, Team Support 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 *really* but a series of lifecycle managem— just kidding. Here it is, the changelog! ## PR Environments at the Project Level [Image: The new Base Environment selector in Project-level settings] [Three weeks ago](https://railway.app/changelog/2023-04-14-pr-environments-verification) 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. This week we’ve added a `Base Environment` 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. Stay tuned! ## Migration to Tailwind Complete [Image: 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 [wrote up a great blogpost](https://blog.railway.app/p/twin-macro-tailwind-migration) explaining the process. Check it out! ## Team Support Upgrades 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. As always, you can reach us using the `Talk to an Engineer` button in the user menu. ## Improvements and Fixes - Nixpacks [updated to v.1.7.0](https://github.com/railwayapp/nixpacks/releases/tag/v1.7.0) - We fixed a bug that sometimes prevented `Restart` from working for services - We fixed a bug that allowed some users to deploy to deleted environments - We fixed a small bug with [featured templates](https://railway.app/templates) - 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