You will need to use the reference variables. Eg, for Postgres database URL, you would use something like ${{Postgres.DATABASE_URL}}

https://docs.railway.com/guides/variables#reference-variables

So would I then just use ${{dev-portal.DATABASE_URL}} and repeat for each service?

If you want to link the newly added 3 services to your redis and postgres, you would have to add ${{ Postgres.DATABASE_URL }} and ${{ Redis.REDIS_URL }} in each one of your 3 services as environment variables.

dev-portal service example:

DATABASE_URL=${{Postgres.DATABASE_URL}}
REDIS_URL=${{ Redis.REDIS_URL }}

Alternatively, you can use Shared Variables in you project settings, to set those variables in one place and share them across your services.

I am trying to link the 3 new servicecs to API, basically my API is going to be the middleman between the 3 new services and the postgres and redis. The 3 new services are the website that need to communicate with the API and then the API will communicate with the redis and postgres. Does that make sense or am I building this all wrong?

Yeah, it totally makes sense to do it this way. Your backend API should communicate with your postgres/redis on behalf of your client services. But in this case, you wouldn't set environment variables for postgres/redis in those 3 services. You only need to link the 3services to the backend API.

Exactly what I thought! Cause they make API calls but some of their calls create data for the postgres so i didn't see the need to have the frontend bypassing the API. I'm self teaching and a novice(like this is my first project of this caliber), and I have never worked with programming outside a mono-repo/executables so trying to understand how to really do this. As it stands, I do have the internal api var in the 3 new services and the 3 new services internal var set to the api exactly as it says so where you get the var from. So I am confused as to why it didn't link after redeploy.

If they are still not linked, you need to provide more info to determine the cause. Such as: error logs and your variables setup in the dashboard (without exposing any secret ones).

So I may not need them to communicate internally since I do have them pointing to the public api endpoints(written directly into my code) and didn't consider the communication errors I was having were coding issues not related to the 3 new services not being directly linked internally. Would linking them internally make a difference?

Yes you should definitely link them internally to the API, as the public connection incurs egress charges. Meaning you will pay extra money for no reason.

Connecting to the API internally ensures your services communicate with the API without any egress usage.

Avoid public connections whenever possible.

OH, that is super good to know. I'll have to look see what i can run internally cause I dont think any of my code currently can serve to the user and communicate internally. I am building a content aggregator but with a uniquely insane new concept, I wrote the blockchain technology directly into the source code and changed the mining and minting process to be less detrimental to the environment and will no longer have any impact on the chip market. It still maintains the complexity of blockchain technology but simplifies the mining process(to what it was always capable of doing). I really hope this does well, I maybe have 2-3 more weeks of solo-dev work to get done before I can fully launch(plus the legal stuff)

But I dont launch that side of the aggregator until i finish my blockchain and smart contract and hammer out the tokenomics final version(tweaking as I do more research on platform hopping) granted I need the data to realllly hammer out how the tokenomics will ultimately operate, but the plan for dencentralization will be creating an executable that users can download to help build a decentralized "network" that'll support the system.