With --tunnel-only, the CLI opens a local SSH tunnel into the selected database service (no public TCP Proxy needed), prints the host, port, user, password, database and connection URL for an external client, and holds the tunnel open until Ctrl+C. The SSH session is authenticated as your Railway user and targets the service and environment you select. That access follows your permissions in the project.

The tunnel encrypts and carries traffic to the database service you chose. We have not confirmed for this answer whether the tunnel itself proves the MySQL server's identity in a way that replaces MySQL-level server authentication. If your policy requires server identity verification at the MySQL layer, treat MySQL TLS certificate verification as a separate control alongside the tunnel, not something the tunnel supplies.

For a single read-only query without enabling public access, railway connect over SSH (with or without --tunnel-only) is the documented path for private databases, and it works when the service has no public TCP Proxy. Pass --environment to pin the environment, and use a MySQL account limited to read-only privileges for the query. See railway connect.

Thank you for clarifying.

Since Railway's SSH tunnel does not establish MySQL-level server authentication, does Railway provide a MySQL server CA certificate or another supported mechanism for verifying the server identity when connecting through railway connect --ssh --tunnel-only?

If not, please confirm that MySQL-level server identity verification is not currently supported through this connection method.

We want to avoid enabling public access or weakening our existing security requirements.

Thank you!

Our earlier reply did not say the SSH tunnel lacks server authentication. It said we had not confirmed that the tunnel replaces MySQL-level server authentication, so if your policy requires server identity verification at the MySQL layer, that should be treated as a separate control from the tunnel.

We cannot point you to a Railway-issued MySQL server CA certificate or another supported mechanism for verifying MySQL server identity through railway connect --ssh --tunnel-only, so MySQL-level server identity verification is not something we can confirm as supported through this connection method.

The rest of the setup is unchanged: the tunnel targets the database service and environment you select, is authenticated as your Railway user, and does not require enabling public access, with your read-only MySQL account limiting what the query can do.

Hello Railway Support,

Thank you for your previous clarification regarding effective pre-deploy commands and their configuration precedence. We understand that these commands cannot be inspected before deployment creation.

I have one remaining question:

Does Railway provide a supported way to enforce outbound network isolation for a disposable service, including during the pre-deploy phase, so that it cannot reach any databases or external services?

We understand that removing database credentials and environment variables does not necessarily prevent network access.

If this capability exists, could you identify the supported configuration and when isolation takes effect?

If it does not exist, a brief confirmation would be helpful.

We're not requesting any configuration changes.

Thank you!

We don't have a service setting that blocks all outbound network access. Our outbound networking settings cover things like Static Outbound IPs and opt-in Outbound IPv6, and a deployed service keeps its outbound IPv4 internet access.

The isolation we do provide is at the private network level. Services in different projects, or in different environments, can't reach each other over the private network. A service in its own project or environment therefore can't reach your databases over railway.internal. It can still reach anything exposed publicly, such as a database with a TCP Proxy or an external API. See How Private Networking Works.

Private-network isolation is a property of the project and environment boundary, so it's in place from the moment the service is created there. It isn't a toggle that switches on at a particular deployment phase.