Hey Railway team,

I've been using PR-env and Focused env for a month now, and it's great.

However, I'm still fighting a few things:

1. Data duplication
2. Cross-env interactions
3. General feedback

1. Data duplication

My main goal is to reproduce the PlanetScale/Neon database branching behavior.

-> One PR = one complete insulated prod-like database.

I want my PR environments to have their own freely readable and writable data copied over from the main prod environment. Without having to pg_dump/restore on every PR. I know I could do this in GitHub Actions (see below); it just does not feel like the "rail...way" of doing things 😇. Should be much simpler.

Workaround I've tried

• Related to (2), pg_dump/restore is clunky because I can't move things internally; I have to go through the public network. Which (egress fees aside) is not very secure, efficient, or practical.
• Right now, I've settled on dropping the PR-env feature entirely and spinning services up from GitHub Actions. This will allow me to pgbackrest from the PITR-enabled production bucket on boot, but I have to maintain a template to pick which service to boot, which not (kind-of duplicating the focused-pr feature, but dumber)

2. Cross-env interaction

• Related to (1), my main complaint is the lack of internal networking between related environments, especially regarding data duplication and moving large amounts of data between environments without using the public network.
• In PR-env, the ability to easily tell some services to link directly to the base/production service, instead of the PR-replicated one. This is maybe the least inconvenient, as I can work around this by using the public network, but it feels like a workaround.

3. General feedback

• I like the way Focused Envs skip unrelated services by default (by analyzing the dependency chain using env variables), but I often need to either boot an unrelated service AND/OR not boot a related service. It would be great to be able to override this at the service level.

Notably, I tried using an absolute value (URL) instead of a ${{RAILWAY_PUBLIC_DOMAIN}} reference to avoid service A being dependent on service B, but it detected the value as a Railway-provided URL and made the link, thus booting the service anyway.

• I find this explanation for base-environment confusing: "Variables from this environment will be used in the PR Environment. If no base environment is defined, the environment connected to the destination branch will be used."

-> What's the difference between "no base environment" and "production" in the case of me only having a production environment + PR envs? I feel like it's the same.

Love the platform; hope this helps get it on par with other providers in terms of simplicity while keeping the great flexibility it already achieves.

Cheers