HOSTING FOR AI-BUILT APPS

Prove a build can reach www.google.com on Yeeted

One Dockerfile, one fetch, one question: can this deployment's build reach an external website? The build itself is the test - probe.py runs during docker build, fetches https://www.google.com, and the build fails if the fetch cannot leave. A deployment that succeeds has already proven the route before the app ever starts.

This is the allowed half of the egress pair. Its sibling, egress-denied, proves a running app cannot reach the same site without a declaration. Together they check both sides of the platform's network promise: declared external access can work, and the default is no external network.

What it does

• yeeted.yaml carries a network_access section declaring exactly one destination: www.google.com over HTTPS on port 443. The platform validates the declaration at deploy and records an access request for the project's owner. The declaration cannot approve itself; an active Admin reviews and approves it, and the approved grant cannot exceed what is declared here.
• probe.py (build time) fetches the target once and writes build_egress.json. Any HTTP answer, including a 30x redirect or a 429, counts as success: the test is reachability, not Google's application response. A DNS failure, timeout, or refused connection fails the build.
• server.py (runtime) serves the record at /egress and /egress/build, plus a live runtime attempt at the same target. The runtime half is informational - see the sibling example for why runtime egress is expected to be denied.

The network_access section

The declaration follows the platform's yeeted.yaml network access spec:

network_access:
  justification: "..."
  use_case: "..."
  requested_until: "2027-06-30T00:00:00Z"
  destinations:
    - domain: www.google.com
      protocol: https
      ports: [443]
      profile: opaque_endpoint
  expected_usage:
    business_requests_per_day: 100
    bytes_per_day: 10000000

Rules worth knowing, all enforced at deploy:

• destinations must be exact DNS names - no IP literals, wildcards, or URL paths. HTTPS destinations must use port 443. Use the opaque_endpoint profile with HTTPS; parsed_http is for plain HTTP.
• requested_until must be in the future and at most 366 days out. Update this file's date before it passes; an expired declaration is preserved but creates no new access request.
• expected_usage needs at least one positive daily figure. These are estimates for review, not hard limits.

Run locally

From python/egress-allowed:

docker build -t egress-allowed . && docker run -p 8080:8080 egress-allowed

Open http://localhost:8080/egress. Your laptop has internet, so the build probe succeeds - locally the example mostly proves the plumbing works.

Deploy and verify

Follow the deployment walkthrough. Deploy this folder. The build runs the probe; a failed fetch fails the build with the probe's error in the build log.

sh smoke.sh "$PREVIEW_URL"

The script checks the served record: the build-phase fetch succeeded and the target is https://www.google.com.

Endpoints

• GET /healthz - ok
• GET /egress - build record, plus a live runtime attempt (informational)
• GET /egress/build - the build-time record the smoke script asserts on

Caveats

• Which networks a build may reach is platform policy, not something this manifest controls. If the platform later restricts build egress to declared endpoints only, the network_access section here is what keeps this example building - after an Admin approves the request it records.
• The runtime attempt reported at /egress is expected to fail on today's platform (runtime egress is default-deny). That is not a defect of this example; it is what egress-denied asserts on purpose.
• The probe fetches once per build and the usage figures are deliberately tiny. This example is a network probe, not a scraping template.

View this guide and source on GitHub