Skip to main content

Release notes

This page records what changes for people using Zero. Internal changes that do not alter what you see or do are not listed here.

September 2026​

September 28​

Networking between projects. Inside the organization, one project does not reach another over the internal network — not even when both are in the same network. The Networks screen creates the network; each project joins it with one of its environments, on the Project network screen; and the owner of the called service uses Authorize project to open that service, on its port, to one project. The permission goes from Not yet allowed to Allowed when the platform applies it, and revoking blocks new connections. See Networking between projects.

Internal project. A project can be Internal (no internet access): no public address, no pull request preview, reachable only through the network. Create it internal from the start under New project, or change it under Project exposure: the public addresses are retained for the project and come back if it becomes public again. See Internal project.

Internal name per service. Each service can have a name on the network, <name>.zero.internal, unique in the network and resolved by the network of whoever asks — two networks can each have their own api. The name opens no access: only a project with permission reaches the service. See Internal name.

Gateway internal entries. In Connectivity, an internal entry gives the network an address such as api.zero.internal, with prefix or exact paths leading to different services — the Gateway's routes, with no internet address — and the list of who can call it. See Gateway internal entries.

CLI, SDKs and agents. The CLI gains zero networks, zero entries, zero projects network, zero projects exposure, zero projects create --internal and zero services internal-name, with typed confirmation for changes that cut traffic and --wait to wait for the rule to be applied. The TypeScript and Go SDKs have the network operations. The MCP server reads the network and the internal entries, but opens no traffic between projects in any mode. See Tools.

September 22​

Users and access, with no invitations. The Users screen shows the organization's identity-provider people, with search, and each one's access to Zero. Grant access takes effect immediately — no invitation, nothing to accept — and the person receives an email that only announces the access, with the normal sign-in link. Create user creates the account in the provider without a password: the provider sends the official email for the person to set one, and Zero never sees the password. Revoke access removes the person from the organization immediately and keeps their account in the provider. Old invitation links no longer work. An account without access that signs in sees "Your account exists, but it does not have access to Zero yet." — and no longer creates its own organization. See Users and access.

http:// redirects to https://. A published address reached over http:// used to time out. It now answers with a permanent redirect to https://, keeping the host, path, and parameters — on the platform's domain and on your custom domain.

An address that goes out of use stays with your organization, with no deadline. Deleting a project or changing a service's address leaves the previous address reserved to your organization: no other organization can use it, and a project of yours can use it again whenever it wants. The 90-day period announced on September 21 no longer exists — a webhook or callback registered with a third party keeps pointing at the address long after that. See Changing the address and Deleting the project.

September 21​

A deleted project's address stays with your organization. Deleting a project left its public address free for any organization at once — and whoever asked for it first would receive the links, sign-in callbacks, and webhooks still pointing to it. Now the address stops serving and stays reserved to your organization for 90 days: another organization cannot use it, and a new project of yours can. After that period it becomes available again. See Deleting the project.

Applications on a custom domain get their DNS record on their own. An address under your subzone — store.apps.acme.com — showed as published while the name did not exist in DNS. Zero now creates each application address's record in the subzone, and removes it when the address stops serving. Addresses answer over https://. See Custom domain.

A deployment that does not come up now fails, and says why. Previously, after a 5-minute wait, the deployment ended Online even with the application not answering. Now it fails with the reason — APPLICATION_NOT_STARTED, APPLICATION_CRASHED_ON_START, or HEALTH_CHECK_FAILED — and the action, on screen, in the API, and in the CLI. Nothing is switched: the previous version, if there was one, keeps answering. Definitive reasons end in about 30 seconds, without waiting for the deadline. See Deployment states.

The timeline narrates the wait. While the platform waits for the application to become ready, the deployment says what is happening — "The application started, but is not accepting connections on port 8080 yet.", "The environment has not managed to pull this version's image yet.". "Version N is live." only appears once readiness has been observed.

The evidence ladder reaches 4 of 4. "Application answering" is now recorded when the instances become ready — the screen used to stop at 2 of 4. "Address confirmed" comes from real traffic, answered by the application; a response generated by the platform when it cannot reach the application does not count. A fresh deployment stays at 3 of 4 until the first real request. See Following a deployment.

Images without USER now run. The process always runs as a non-root user, with UID and GID 10001, whatever the image's USER. Images without USER — like most official language images, node:18-alpine for example — and images with USER by name, such as USER node, used to be refused before the container existed; now they work. The full contract — read-only file system, /tmp writable up to 512 MiB, HOME at /tmp, PORT defaulting to 8080, readiness by TCP connection — is in How the application runs.

Deployment in progress, with no reload and with details. After you deploy, the deployment shows up right away under Deployments, in the Deployment in progress section, with the name of the current stage and who deployed. View details is there from the first second: stages and the platform's narration, live, and Open the Deployment once it is born. The Deployment enters the table on its own, the Origin column shows the deployed commit and the Author column, the name of who deployed.

One address per service, and a change that says what it releases. Old addresses no longer pile up. Changing the address under Domains asks for confirmation and redeploys the live version with the new address, without rebuilding — it shows up in Deployments as Address change. The previous address stops answering once the new one is live, with no gap without an address, and becomes free for anyone to use. See Changing the address.

The source belongs to the project, with GitHub, GitLab, and Bitbucket. One repository per project; services only choose the folder and the reference. The field accepts a full URL, an SSH address, or owner/repo, and GitLab accepts subgroups. Save source says what is missing from the address, and the access token never comes back to the screen. See The project source.

Deleting a project, with its history preserved. Deleting asks for the project's name, typed, and accepts a reason, which goes into the audit trail. Once the deletion completes, the project disappears from every read, its name becomes free, the queue is cancelled, and the source is revoked; audit, operations, deployments, and versions stay recorded. See Deleting the project.

Custom domain available. Zone creation is available. The delegation is checked in three layers, and the Propagation pending state, normal in the first few minutes, is checked again on its own. For names at the main level, with no subzone, there is the Keep my current DNS path. See Custom domain.

CLI, SDKs, and MCP. zero deploy exits with 0 when the deployment becomes ready and 1 when it fails, with the reason. zero projects delete and zero source set arrived. In the SDKs, changing the address returns operation_id and previous, a domain can be in releasing, and a field that may be null is now typed as nullable. The MCP server was regenerated from the same contract. See Tools.

August 2026​

Promotion between environments, without rebuilding. The version approved in one environment ships to another exactly as it is — the same image, identified by content. "The same commit, rebuilt" produces a different artifact, and Zero does not pretend otherwise. Available in the console, in the CLI (zero promote) and in the API. See Promoting between environments.

Scale and availability on one screen. The number of instances, autoscaling and the size of each instance now live together, in the order people ask about them. The screen shows how many instances are up, not just how many were requested. See Scale and availability.

Automatic high availability. A service's instances are now spread across different machines, and maintenance removes one at a time. It is not a setting to turn on: it applies to every published application, from its next deployment. The protection is against machine failure, not zone failure — and that is written on the screen.

Tools to download. The CLI, the MCP server for AI agents and the TypeScript and Go SDKs now have an official place to get them, with published checksums: zero.nnumbers.com.br/downloads. See Tools.

Product website. zero.nnumbers.com.br now serves Zero's website. The address previously returned 404 to anyone arriving in a browser.

Product vocabulary. Screens now use instances, instance size, autoscaling and high availability — each term answers a real question, and "autoscaling" kept the name the technical audience recognises.

Custom domain through a delegated subzone. An organization can delegate a subzone of the company's domain — apps.acme.com — and publish applications under it. Delegation is done once, with four NS records, and the console walks you through the steps for the DNS provider you use. No DNS credentials are requested or stored. See Custom domain.

The zone comes before the address. When creating a project, the domain choice now appears before the address choice, because the zone is its base. The availability check is now about the final address, not about the name inside the organization.

History of deployment attempts. Deployments that fail before committing a version — an unreachable repository, a branch that does not exist — now appear in the project, with the reason. They used to vanish.

Resources and limits per service. Reserved, maximum, applied, and observed usage appear side by side. Saving redeploys the service with the same image, and the screen follows the operation to its outcome.

Capabilities declared by the server. Screens whose capability does not exist in this installation now say so, in the sentence the server sends, instead of showing "not found".

July 2026​

Console reorganized around the project. The project became a place rather than a filter: navigation enters it and the sidebar changes content. The word "application" left the interface — the project is the application. The service layer appears only when there is more than one.

Production is created with the project. You no longer need to create an environment before deploying for the first time.

Build log recorded in both outcomes. The builder's output is now kept for successful deployments too — which makes it possible to investigate a slow build or one that produced the wrong image.

Observability with three distinct silences. "Collection not configured", "collecting, no traffic", and "collecting, with traffic" stopped being the same "no data". Absence stopped becoming zero across every reading.

Next steps​