Changelog

Compute services can now take UDP traffic. Pick the udp endpoint, or tcp+udp to serve both on one port.

From the CLI, set it when you add the service or deploy it:

insta service add compute <service> --port 9000 --endpoint udp
insta deploy --image <image> --group <service> --port 9000 --endpoint udp

In the dashboard, set Endpoint to UDP or TCP+UDP in the service's Settings tab. Changing it redeploys the service on the same image.

How clients reach it

The service gets its own public IPv6 address and takes UDP on the port you chose. Clients need IPv6, the platform adds no TLS, and a UDP service can't have a custom domain. Known amplification ports such as 53, 123 and 11211 are refused. Other services in the same project branch reach it at <name>.insta.internal, the same as any service on the private network. Compute services in other projects can't reach a UDP endpoint yet.

Waking up

A datagram wakes a suspended service. Datagrams that arrive while it wakes are re-sent until the service first replies, so your app may see one more than once. A service that only receives and never replies counts as idle and is suspended again, so turn on Always On for it.

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.

Deployed templates can now be updated to their newest version.

From the CLI

insta template upgrade <service>

Pass any service the template deployed.

From the dashboard

A template with a new version shows Update available on its card on the canvas. Click it, or Review update in the service's Settings under Source, to stage the update, then press Deploy in the Changes bar.

You can now create a Postgres service on PG 16, 17 or 18. Choose the version your app needs when you add the service.

From the dashboard

There is a new dropdown in the Add Service dialog that lets you select the PG version. Once the service is created, its Settings tab shows the current PG version. The version can't be changed after creation.

From the CLI and MCP

insta service add postgres <db> --pg-version 18

Without --pg-version, the database is created on PG 16. Over MCP, pass pgVersion to insta_add_service.

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.

A shell into a compute service runs inside your image's own filesystem. On a slim, alpine, distroless or FROM scratch image that used to mean no curl, git or gh: an agent could get in and then do nothing.

Sessions now find curl 8.15.0, git 2.50.1, gh 2.101.0 and jq 1.8.2 on their PATH, mounted read-only at /.insta/tools. That covers ssh <service>.insta, the dashboard Console tab and insta compute exec, so an agent can clone a repository or open a pull request from inside the service without rebuilding the image.

The toolbox is last on PATH, so a tool your image ships always wins. It is on the session's PATH only: your app's process sees the same environment as before, and anything it needs at runtime still belongs in the image. curl and git carry their own CA bundle, so https works in an image without certificates. gh uses the GH_TOKEN in your service's variables; InstaCloud injects none.

A scale-to-zero compute service suspends when it goes idle and wakes on the next request. Until now, idle was judged from inbound traffic only: HTTP requests, SSH sessions and open TCP connections. A background worker or an agent on a long task can take nothing in for minutes, and the platform could suspend it mid-job.

Outbound traffic now counts as activity too. A process that is calling a model or polling a queue keeps its service awake for as long as it keeps talking. The service still suspends once it goes quiet in both directions, so an idle one costs what it did before.

Nothing to configure

Every scale-to-zero service picks this up on its own. If you switched a service to always-on only so a long task would survive, you can switch it back:

insta compute always-on off <service>

Outbound traffic keeps a running service awake; it does not wake a suspended one. A service whose work only ever starts from its own side, like a bot polling on a timer, still needs always-on.

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.

Compute volumes no longer have to live at /data. You can pick the mount path when you attach a volume, and change it later on a volume that is already attached. That makes it easy to run an image that expects its data somewhere specific, like a database under /var/lib/postgresql or an app that writes to /app/storage.

Pick a path

In the dashboard, the Mount Path field sits in the service's Volume tab and in the create dialog. From the CLI, pass --mount-path when you create a service with a volume, or when you attach one to an existing service:

insta service add compute web --volume 1 --mount-path /app/storage
insta compute volume web --size 1 --mount-path /app/storage

Leave it out and the volume mounts at /data, as before. The path has to be absolute. System directories such as /etc, /usr or /proc are refused.

Move an existing volume

Changing the path of a volume that is already attached is staged, not applied on the spot. The dashboard shows it as pending until you deploy. From the CLI, stage it, then restart:

insta compute volume web --mount-path /srv/data
insta compute restart web

compute restart needs the service to already be running. If you've stopped or suspended it, start it first with insta compute start, or make the change from the dashboard's Deploy flow instead.

The service stops, the same disk is mounted at the new path, and the service starts again. Your files stay on the volume, and nothing is copied or resized. Your app's own configuration is not rewritten, so update any paths that point at the old location in the same deploy. In the dashboard, variables, the mount path and the startup command can all go out in one Deploy.

You need CLI 0.1.3 or newer to change the path of an existing volume. Managed database volumes keep the paths the platform chose.

Every branch can now run cron jobs. A cron job sends one HTTP request on a schedule, either to a compute service in your project or to any external URL. You don't need a worker process or an always-on machine to keep the clock running.

Create a job

Expressions use standard 5-field cron syntax and always run in UTC. This one calls /tasks/nightly on the api service at 03:00 UTC every day:

insta cron preview '0 3 * * *'
insta cron create nightly-report '0 3 * * *' --service api --path /tasks/nightly

preview validates the expression and prints the next five fire times, using the same parser the scheduler does. To call something outside InstaCloud, pass --url https://… instead of --service. --method POST, --body and --header name=value shape the request. Header values are encrypted at rest and never shown again: insta cron show lists header names only.

In the dashboard, Cron Job is an entry in Add Service. Each job appears as a card on the services canvas, with an edge to the service it calls. Edits go through Deploy like every other change on the branch. Pause and Run now take effect immediately.

What happens when it fires

A job that targets a service names the service, not a URL, so a redeploy or a region move can't leave it calling a dead host. If the service is idle, it is woken first, and the time spent waking doesn't count against the request timeout. If the previous run is still going when the next tick arrives, that tick is skipped. The same happens if the platform is more than five minutes late for a tick, rather than delivering it long after it was due.

insta cron runs <name> shows each run's status, attempts, HTTP status, and how long the wake and the request each took. A slow wake is on us; a slow request is your endpoint. pause, resume, run and delete do what they say, and a deleted job stops firing immediately.

Cron needs CLI 0.1.3 or newer. Free organizations can keep 5 jobs, Pro 100, and Team and Enterprise 1,000.

Every compute service now has a Console tab in the InstaCloud dashboard. Open it and you get a shell inside the service's VM, over the same SSH gateway the CLI uses, with nothing to install on your machine. It sits between Variables and Logs on the service page.

How a session works

The tab connects as soon as you open it. Being signed in to the dashboard is all it takes: no key to generate, no CLI to install. Ctrl+C, paste and resizing the window all work.

What you run in Console runs directly on the instance. Leaving the tab, switching services or waiting past 30 minutes closes the session, and Reconnect opens a fresh shell. On a service with several replicas the gateway picks one for you. An idle service wakes when you connect, and a stopped one asks you to start it first.

Console is for people. An agent that needs to run commands still uses insta compute exec.

From your own terminal

The SSH access that shipped on September 18 is unchanged. Use Console for a quick look; use ssh <service>.insta when you want scp, port forwarding or your own tooling:

insta compute ssh dev-agent --setup
ssh dev-agent.insta

InstaCloud now supports SSH access to your compute services. Open an interactive shell inside the service's own VM to inspect files, debug a running app, or run commands with its environment available.

Connect from your terminal

With CLI 0.0.79 or newer, run the one-time setup for your service on your machine, then connect with SSH. For the insta-dev-agent service shown above:

insta compute ssh insta-dev-agent --setup
ssh insta-dev-agent.insta

The CLI creates a dedicated local key, obtains a short-lived certificate, and configures a <service>.insta SSH alias. Certificates renew automatically when you connect. Authentication uses certificates, with no SSH password to manage. The alias also works with scp and local port forwarding (ssh -L).

You can find the connection command in the service's Settings → General → SSH section. To get a connection command without configuring an alias, run insta compute ssh <service>. This issues a certificate and prints the command; it does not open the session itself. For commands from CI, please use insta compute exec.

You can now buy a domain using InstaCloud. Search for a name, pay, and InsForge registers it on your behalf: no registrar account, no contact forms, no SSL certificates to renew. InstaCloud manages the nameservers and DNS records for you, so your domain goes live with nothing to configure.

Attach your domain to any compute service

insta domain search myapp
insta domain buy myapp.com
insta domain attach api.myapp.com --group my-api-service

The above commands buy the domain myapp.com and attach it to my-api-service. You can ask your agent to run them, or do it manually by purchasing the domain from the Domains page and then attaching it to the service you want.

You can manage DNS records for each domain too, adding your own to point at any external service you use.

InstaCloud now supports project-level agent governance policies. Choose which operations your agent can run, which need human approval, and which are blocked. The same policy applies to agent-mode CLI requests and MCP tools; human requests keep their existing role-based permissions.

Choose how your agent works

• Full access: Allow classified project operations within the user's existing permissions. This is the default for new and existing projects.
• Read-only: Block operations classified as mutations while allowing reads, including sensitive credentials.
• Branch-specific: Let agents develop on unprotected branches, block classified writes to protected branches, and require approval for operations such as deleting services or changing capacity.
• Custom: Set individual eligible actions to Allow, Approve, or Deny. Protected-branch writes remain blocked.

Select protected branches explicitly; main is not protected automatically. A human project admin can configure the policy in the console or CLI. For example, to allow development on other branches while protecting main:

insta agent-policy set branch-specific
insta agent-policy protect-branch main

Review requests before they run

When an operation needs approval, it pauses for a human admin to review. Approval authorizes one exact request once. The agent then retries the unchanged command; changing the resource or parameters requires a new approval. Agents cannot approve their own requests, and restricted modes prevent them from changing their policy or branch protection.

These policies govern operations through the official agent toolchains. Read-only mode and branch protection do not enforce SQL-level isolation: SQL queries are not parsed for writes, and database credentials can permit direct access.

Compute services now run as full Linux VMs with cgroups and root, so your agent can install Docker inside its own compute and use it the way it would on a laptop: build images, run containers, wire them together. Nothing is preinstalled and nothing to enable.

Give the service a volume, put Docker on it, and start the daemon. This is a stock Debian image:

insta services add compute app --image nginx:bookworm --port 80 --volume 2
insta compute exec app -- sh -c 'apt-get install -y curl iptables && curl -fsSL https://download.docker.com/linux/static/stable/x86_64/docker-27.5.1.tgz | tar -xz -C /data'
insta compute exec app -- sh -c 'setsid nohup /data/docker/dockerd --data-root=/data/docker-root >/data/dockerd.log 2>&1 </dev/null &'
insta compute exec app -- /data/docker/docker run --rm alpine echo hello from inside your compute

Keep Docker and its data on the volume. The root disk is sized to your image and rebuilt on every wake, so anything under /data survives sleep and wake, and anything else doesn't. Idle is still measured by traffic: a Docker stack sleeps with the service and comes back on the next request, so turn on always-on if it has to run with nobody calling it.

Any repository carrying an insta.template.yaml can now deploy straight from its GitHub link, without publishing to the official registry. Hand the prompt to your coding agent:

Deploy the template at https://github.com/InsForge/insta-oss/tree/main/templates/n8n into this project

If the repository has no manifest yet, the agent can write one, since the InstaCloud skill now documents the format.

Write an insta.template.yaml for this repo and deploy it

Requires CLI 0.0.62 or newer, and git on your PATH. Run insta upgrade to get it.

Compute services without a persistent volume can now run multiple replicas in the same region. Each replica runs the same deployed image and configuration, and traffic is balanced across them to improve availability.

Configure replicas

From the dashboard, you can configure the number of replicas in each service's Settings tab, or ask an agent to make the change through the Insta CLI or MCP. For example, this command scales my-api-service to three replicas:

insta services scale compute my-api-service 3

With MCP, the equivalent call is insta_service_scale with count: 3.

This is a paid-plan feature with up to 10 replicas per service. You can contact us if you need more. Multi-region replicas are coming later.