Changelog

Services in the same project branch can now reach each other over a private network, without going through their public URLs.

Private addresses

Every compute service has a private address, <name>.insta.internal, on the port it listens on. A managed Redis, MySQL or MongoDB is at <name>-<type>.insta.internal, and its private connection string sits beside the public one as REDIS_PRIVATE_URL, MYSQL_PRIVATE_URL or MONGODB_PRIVATE_URL. Bind it like any other credential:

insta secrets bind REDIS_URL redis/cache --source-name REDIS_PRIVATE_URL --to compute/app

Each branch is its own network. On a preview branch, api.insta.internal is that branch's api, and nothing in one branch can reach another branch's services. A service's Settings tab shows its private address, and insta compute public-access <service> prints it. A service that was already running before this release resolves the short names after its next deploy or wake.

Close public access

A service that only your other services call doesn't need a public URL. Switch off Public Access in its Settings tab, or:

insta compute public-access off <service>

From then on its URL answers 403 without waking it, so a scanner on the internet can't keep it running. Services in the same branch still reach it at its private address, and public-access on reopens it. Managed databases have the same switch: after insta mysql public-access off <service>, MYSQL_URL stops connecting and only apps in the branch reach the database, through MYSQL_PRIVATE_URL.

A cron job calls its target's public URL, so it can't target a compute service with public access closed.

Every Postgres database on InstaCloud has sat on a public hostname, open to anyone with the password. You can now give a database a private route that resolves only inside InstaCloud compute, then close the public one.

Turn on private access

In the service's Database tab, switch on Private Network under Network Access. InstaCloud mints DATABASE_PRIVATE_URL beside DATABASE_URL, which is left as it is, so a running app changes nothing until you rebind it and redeploy:

insta secrets bind DATABASE_URL postgres/<db> --source-name DATABASE_PRIVATE_URL --to compute/<service>

The private host resolves from compute services on InstaCloud, in the database's region or any other, and never from a laptop or CI. Traffic on it stays off the public internet. It wakes a suspended database just as the public route does, and a branch or fork of the database gets a private URL of its own.

Close public access

With private access on, switch off Public Access. The dashboard first lists what will break: compute services still bound to the public URL, and anything outside InstaCloud such as CI or a local psql. From then on the public endpoint refuses connections before it wakes the database, so an internet scanner cannot keep it awake and billed. The change reaches the proxy within about 30 seconds, and connections already open stay up.

A closed database is not reachable from the internet. Other workloads on the InstaCloud compute plane can still reach the private endpoint, and they still need the password.

You can now mint an API token and drive InstaCloud from a script or a CI job: create a project, add services, deploy, run SQL. The dashboard, the CLI and the MCP server all use the same REST API at api.instacloud.com, so anything they can do, a token can do too.

Scope, access and expiry

A token is bound to your account, to one organization and its projects, or to one project, and the scope is fixed when you create it. Access is full or read-only: a read-only token can list and inspect but not run SQL or change anything. Expiry defaults to 90 days, or never for a token you rotate yourself.

A token never exceeds its owner. Your organization role still applies, and leaving an organization revokes the tokens you minted there.

Create one

In the dashboard, open API Key under Profile. From a terminal, the same token is one command:

insta tokens create ci --project <id> --read-only --expires 30d

The plaintext is shown once. Both places list your keys and revoke them, and a revoked key stops working immediately. On a CI runner, insta login --api-key signs the CLI in with the token instead of a browser.

Call the API

Send the token as a bearer credential. This adds a Postgres service to a project:

curl -s -X POST https://api.instacloud.com/projects/$PROJECT/services \
  -H "Authorization: Bearer $INSTA_TOKEN" -H "Content-Type: application/json" \
  -d '{"type":"postgres","name":"db"}'

A request outside the token's scope answers 403 token_scope. The API reference says which scopes each endpoint accepts.