Set up Infrapilot

You are a coding agent, and the person you are working with has asked you to set up Infrapilot for the project in this repository. This page tells you everything you need. Follow it from top to bottom; each API response also tells you the next step.

Infrapilot is a hosted service. Its agent, Pilot, runs in its own sandbox in Infrapilot's cloud and operates the person's cloud account around the clock: it keeps declared objectives true, inside limits the person sets, and asks people when it needs a limit moved. You are not installing anything. You are (1) giving Pilot scoped access to the cloud account, (2) writing down what Pilot should run and what must stay true, and (3) starting it.

What done looks like

• GET https://18-207-170-166.sslip.io/api/v1/setup/status returns "ready": true.
• An infrapilot.yaml at the root of the repository describes the fleet (commit it; it holds no secrets).
• You have told the person: what Pilot now manages, the objectives and limits you set, where its requests will go, and the dashboard link.

Ground rules

1. The setup token is a secret. Keep it in a shell variable for this session. Send it only to https://18-207-170-166.sslip.io as Authorization: Bearer <token>. Never write it, or any cloud credential, into a file in the repository, a commit, or a log.
2. Ask the person before (a) creating access in their cloud account, (b) settling the cost ceilings and bounds in the spec, and (c) starting Pilot. Show them exactly what you are about to do. Everything else you can do on your own.
3. Do not guess limits. A cost ceiling or an objective you invent will be enforced. Propose values from what you find (current configuration, traffic, the bill) and confirm them.
4. Pilot never needs more than the role you create. Grant what the provider page says, scoped as narrowly as the person wants. Nothing here needs administrator access to be handed to Pilot.
5. If a step fails, read the error. Errors from this API say what is wrong and usually how to fix it. Fix the cause and repeat the step; do not skip ahead.

Put the token in the environment first (replace the value with the token from the prompt you were given):

export INFRAPILOT_TOKEN='ipsetup_...'
export INFRAPILOT_URL='https://18-207-170-166.sslip.io'

0. Read the workspace

curl -s -H "Authorization: Bearer $INFRAPILOT_TOKEN" $INFRAPILOT_URL/api/v1/setup

The response tells you:

A 401 means the token is wrong, expired (they last 14 days) or was replaced. Ask the person for a new prompt from the dashboard.

1. Connect the cloud account

Read the page for the workspace's provider and follow it:

• AWS: https://18-207-170-166.sslip.io/docs/aws.md
• Azure: https://18-207-170-166.sslip.io/docs/azure.md
• Google Cloud: https://18-207-170-166.sslip.io/docs/gcp.md

Each ends with POST /api/v1/setup/cloud. Infrapilot then checks the connection from inside the workspace's sandbox, which is the only place the credentials are ever used. A successful response looks like:

{"ok": true, "account": "921008910388", "checks": [{"check": "credentials", "ok": true, "detail": "..."}], "next": "write_manifest"}

A 422 lists the checks that failed. Fix the access (the provider page says what each check needs) and submit again. A newly created role or service principal can take up to a minute to become usable; if the first check fails with an access error right after you created it, wait 15 seconds and resubmit once before changing anything.

2. Work out what Pilot should run

Look at the repository and, with the provider's CLI, at the account. You are answering three questions.

What already exists that Pilot should run? (mode existing) Find the production resources this project uses: functions, containers, queues, tables, databases, autoscalers. Pilot adopts resources by tag (labels on Google Cloud). Tag each one with the fleet name and a short logical name; the provider page gives the commands. Tagging changes nothing about how a resource behaves. Do not tag things that belong to other projects.

What should exist but does not? (mode new) List the workloads the project needs, in plain terms: an HTTP service from this container image, a queue, a private bucket. Pilot builds them from each provider's blueprint. See the workload kinds on the provider page.

What must stay true? For each thing users or the business would notice, write an objective: a metric that must stay under a number. Good objectives are the ones someone would be paged for: latency of the public API, backlog of the order queue, throttled writes on the main table. Take the threshold from an SLO if the project has one; otherwise look at the last two weeks of the metric and propose a value with headroom, then confirm it.

To see exactly which resource types, objective metrics and workload kinds Pilot understands on a cloud:

curl -s $INFRAPILOT_URL/api/types/aws      # or azure, gcp

3. Write the fleet spec

Write infrapilot.yaml at the repository root. The full reference is https://18-207-170-166.sslip.io/docs/manifest.md; read it before writing. A small real example:

version: 1
fleet: shop                      # lowercase, digits and dashes
provider: aws
region: us-east-1
adopt:
  - tag: {"infrapilot:fleet": "shop"}
intents:
  - name: checkout API stays fast
    description: The checkout API answers within 400 ms at p99 and never throttles.
    objectives:
      - {resource: api, metric: Duration, stat: p99, below: 400}
      - {resource: api, metric: Throttles, below: 1}
    max_monthly_cost_usd: 150
    bounds:
      api.MemorySize: [128, 2048]
boundaries:
  manage: profiled
  create_types: []               # Pilot may not create anything in this fleet
  protected: [orders-db]         # Pilot may never change these

Before submitting, show the person the intents, the cost ceilings, the bounds and the protected list, and get a yes. Then submit the file as it is:

curl -s -X PUT $INFRAPILOT_URL/api/v1/setup/manifest \
  -H "Authorization: Bearer $INFRAPILOT_TOKEN" -H "Content-Type: application/yaml" \
  --data-binary @infrapilot.yaml

A 422 returns errors: a list of every problem, each naming the field. Fix them all and resubmit. provider, region and scope may be left out; they are filled from the cloud connection.

Now check what the spec would adopt. This reads from the account and changes nothing:

curl -s -X POST -H "Authorization: Bearer $INFRAPILOT_TOKEN" $INFRAPILOT_URL/api/v1/setup/discover

• resources: everything the adopt rules match, with the logical name Pilot will use for each. Objectives and bounds must use these names.
• owned_by_controllers: values a provider autoscaler already owns. Pilot will tune that autoscaler and never write those values. This is expected.
• missing: resources an intent names that were not found. Either the tag is missing, the name is different (fix the spec to use the discovered name), or the provider's tag index has not caught up yet (wait a minute and run discover again).
• to_build: declared workloads Pilot will create.

Do not continue while missing is not empty. Show the person the final list of what will be adopted.

4. Say who decides

Pilot asks people when it reaches a limit: a cost ceiling too low for the traffic, a bound that caps the one lever that works, an operation only a person may approve. The workspace owner's email is already a contact. Ask the person who else should get these requests and add them:

curl -s -X POST $INFRAPILOT_URL/api/v1/setup/contacts \
  -H "Authorization: Bearer $INFRAPILOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"email": ["oncall@example.com"]}'

Slack, Microsoft Teams and phone (text message) are also supported: see https://18-207-170-166.sslip.io/docs/requests.md. This step is optional; skip it if the owner's email is enough.

5. Start Pilot

Confirm with the person, then:

curl -s -X POST -H "Authorization: Bearer $INFRAPILOT_TOKEN" $INFRAPILOT_URL/api/v1/setup/start

The workspace's sandbox starts. Pilot adopts the resources, records the intents, and reviews the fleet. Poll until it is ready (usually under two minutes; building workloads from nothing takes longer):

curl -s -H "Authorization: Bearer $INFRAPILOT_TOKEN" $INFRAPILOT_URL/api/v1/setup/status

{"ready": true, "agent": {"state": "running"}, "resources": 7,
 "objectives": [{"objective": "api Duration p99 < 400", "status": "ok", "value": 212.0}],
 "first_review": "All three objectives are met. ...", "open_requests": [], "dashboard": "https://18-207-170-166.sslip.io/app#/ws_..."}

If agent.error is set, the sandbox could not start; the message says why (most often the access from step 1 was changed or removed). If ready stays false for more than five minutes with no error, tell the person and give them the dashboard link; do not keep polling.

6. Confirm and hand over

Tell the person, briefly:

1. What Pilot now manages (the adopted resources and any workloads it is building), and what you tagged.
2. Each intent with its objectives, cost ceiling and bounds, and what is protected.
3. What Pilot said in first_review, and any open_requests (it may already have found a limit worth moving).
4. Where requests go, and that an approval is one tap from the email.
5. The dashboard link from dashboard, where the ledger shows every change with its reasoning.
6. That infrapilot.yaml is the record of the spec. To change an objective or a limit later, edit it and submit it again with an API token from the dashboard (https://18-207-170-166.sslip.io/docs/api.md), or edit it in the dashboard.

Commit infrapilot.yaml. Unset the token: unset INFRAPILOT_TOKEN.

If something fails

Nothing in this process changes how the person's infrastructure behaves until Pilot starts, and from then on every change is in the ledger with a reason and a ready-made undo. To stop Pilot at any time: the dashboard's Settings page, or remove the role you created in step 1.