carlos / platform Public

Answer: an operator-granted, per-app egress allow. Not built yet; this is the ruling, and a build follows.

Today nothing reaches a private address from an isolated instance except the box's DNS resolver (carlos-instance-gen@.service, isolated-exec spec §Egress). The two alternatives don't fit now:

• A doc-engine route is served by the public edge like any route, so reaching one means Gotenberg on the internet behind its own auth. That's a platform gap in its own right, filed as #335.
• A socket bound into the namespace can't reach an engine on another box without a relay the platform doesn't have yet (also #335).

The shape:

• carlos apps set <app> --egress-allow <address>, operator-only, recorded, and shown in carlos apps show.
• Rendered as IPAddressAllow= on each of that app's per-instance slices (carlos-instances-<host>.slice, which the control service already writes at runtime). It reaches only that app's instances, and an allow beats the template's deny.
• Per app, not per host. This is a deliberate exception to the capability rule that grants are --host only. Grant by grant, 117 accounts plus one for every new account is worse, and the risk is one named address, not a port or a cloud role.

Limits that come with it:

1. Address only, never a port. IPAddressAllow= can't name one, and it opens the address both ways. :443 would be a promise the platform can't keep. Your security group decides the ports.
2. Opening Gotenberg reopens the VPC by proxy. An engine fetches whatever a document names. Before granting it, fence Gotenberg's box: deny egress to RFC 1918, link-local and CGNAT ranges in its security group (the doc_engine deny list is the model) and keep Chromium's deny-list on. Otherwise an isolated tenant's HTML can reach anything the PDF box can.
3. Provider-neutral: a plain address allow.

Titogo-side: TITO_GOTENBERG_URL stays as it is. Once the allow is granted and the instances restart, the PDFs work again.

Thanks, the per-app egress allow works for us. We'll fence the Gotenberg box's egress (RFC 1918, link-local, CGNAT, with Chromium's deny-list kept on) before asking for the grant.

Four questions so we can plan around it:

1. When: which release will carry --egress-allow, and roughly when?
2. Coverage: does the allow reach every unit an instance can run as: the instance itself, a generation while two builds run at once, carlos run command units, and seeds? And does it carry over when a box re-isolates an instance or a revert moves it back to flat?
3. New accounts: does an account created after the grant pick it up automatically from the app, with no per-account step?
4. Visibility: can we see that the allow is in force on a running instance (in carlos instances list, status --layout, or the probe), so we can confirm it before relying on it?

Also: #315's fix and #316's status warning are merged but not released. Could they go out in the same release as the egress allow, so we roll once?

Answers to the four questions. The design is approved (spec docs/superpowers/specs/2026-10-21-instance-sizes-and-egress-design.md on branch instance-egress-sizes-328-329, rev 9); the build has not started.

1. When. In the first release after its plans 1 (policy foundation) and 2 (egress) are built and merged. No date yet; I'll post here when it merges. #315 and #316 are already on main, so any release cut from main carries them; release timing is Paul's call.
2. Coverage. Yes. Every unit an isolated instance runs as sits in the instance's own slice, and the allow is written there: the instance itself, both generations during a swap, carlos run command units, seeds and sidecar units. Root writes it on every start and re-checks what systemd holds every 30 seconds, so a revoke cannot quietly stay open. Re-isolation picks it up at the next start. A revert to flat needs nothing: flat instances have no private-range fence. Two limits: - A box hosting any flat sidecar member (Kind "sidecar" rows) gets no allow at all, because a flat process may be able to write the registry root reads. - On a box with host claims on, allows are not supported yet (your boxes run without claims).
3. New accounts. Yes. The allow is per app, so an instance created after the grant gets it with no step.
4. Visibility. carlos status --layout gains an EGRESS column, and carlos instances list the same, showing the list read back from systemd for that instance, not the request. ! plus a reason marks any difference (an address refused, the policy expired, the box not wholly nested).

Also worth planning around: the grant is a single address, never a port (your security group decides ports), and the policy is a signed record that expires 72 hours after signing. The console re-signs it every 12 hours, so only a console down for more than about 60 hours closes the allow.