Skip to main content

Internal Project

Every project has an exposure: Public, the default, where web services have an address on the internet, or Internal, where the project has no public address at all. An internal project is reached only from inside its own environment and by the projects it authorized on the network.

Use an internal project for what should never answer the internet: the API only your frontend calls, the billing service, the queue processor with an HTTP dashboard.

What Changes in an Internal Project​

PublicInternal
Internet addressYes, one per web serviceNo
Pull request previewYesNo
Custom-domain route on the GatewayYesNo
Reachable over the internal networkBy whoever has permissionBy whoever has permission

The HTTPS check in the security report shows as not applicable for an internal project: there is no public address to protect.

Before You Start​

  • Changing the exposure requires write permission on the project.
  • If the project receives traffic through a custom domain on the Gateway, that domain's routes must go first — whoever administers the organization removes them in Connectivity.

Step by Step​

Create the Project Already Internal​

In the console, under New project, pick Internal (no internet access). With the CLI:

zero projects create billing --internal

No public address is reserved. Asking for an address in the same creation is refused: it is a contradiction.

Make an Existing Project Internal​

In the project, on the Project network screen, under Project exposure, pick Internal and confirm. With the CLI:

zero projects exposure <project> internal

The CLI asks for the project name, typed; in a script, use --yes. --wait waits for the change to be applied.

What happens:

  1. The public addresses are retained for the project. They appear under Addresses retained for this project, and no other organization can use them.
  2. Pull request previews are closed. They come back only on the next event of each pull request, if the project becomes public again.
  3. The published services are redeployed without rebuilding the image, so the public routes go away. Follow along in Deployments.
Until the platform applies it, the internet can still reach it

While the exposure shows May still be reachable from the internet, the project still answers at its public address. The screen shows when it is done.

Back to Public​

Pick Public the same way, or run zero projects exposure <project> public. The web services get an address again — the retained ones first, with the same name, if the retention continues and the zone still serves. A service that cannot have an address stays without one, shows the reason, and you pick one in Domains.

Restoring a Version​

A version prepared while the project was internal cannot be restored after it became public again: restoring it would take the web service off the internet. Deploy the current version again, or pick a version prepared with the project public. See Restore a version.

Common Errors​

SymptomCauseWhat to do
"The project still receives traffic through a custom domain"There are custom-domain routes on the Gateway for the project's servicesAsk whoever administers the organization to remove those routes first
"An internal project has no public address"An address, a custom-domain route, or a preview was requested for an internal projectChange the exposure to public first
"This version was prepared with the project internal"Restoring an internal version in a project that is now publicDeploy the current version again, or pick another version

Next Steps​