Railway automation gaps: gRPC TCP proxy + managed Postgres with pgvector

Question

We're building a fully hands-free (“curl-to-running-service”) installer for Railway (<https://goodmem.ai/quick-start>) that provisions:

* a Postgres backend
* a memory layer (GoodMem) which connects on startup and runs:  
```  
CREATE EXTENSION IF NOT EXISTS vector;  
```

Today everything can be automated via the Railway CLI except two items.

1) gRPC exposure (TCP proxy) Our service exposes REST (via Railway domain) and gRPC on port 50051\. REST is fully automated, but gRPC requires manually adding a TCP Proxy in the dashboard (Service → Settings → Public Networking).

**Question**: Is there a supported way to create a TCP Proxy programmatically (Railway CLI or Public API / GraphQL), so gRPC can be exposed without UI steps?

### 2) Managed Postgres + pgvector availability

Railway offers a managed Postgres service, but we only want to use it if we can guarantee that `pgvector` is available so our app can run:

```
CREATE EXTENSION IF NOT EXISTS vector;
```

with zero manual steps.

Questions:

* Does Railway-managed Postgres reliably include `pgvector` (and for which Postgres versions)?
* Is there any supported way to ensure pgvector availability at provision time via CLI/API?
* If not, is the recommended approach to run Postgres as an image service when extensions like pgvector are required?

**Current workaround**

We currently deploy Postgres from an image so pgvector is guaranteed:

```
railway add --image pgvector/pgvector:pg17 --service postgres

```

This works, but I'm looking to adapt to Railway-recommended patterns if these are solvable.