Create infrastructure for a service

This guide follows one of Polo’s three acceptance journeys: “Create infrastructure for this service”. Polo writes the Terraform in its own workspace copy, validates it, opens a draft pull request for review and, if you ask for deployment, plans the merged code and applies exactly the plan a person approved.

Note

This journey has run end to end locally, with a local model, a real Terraform runner and two people so that the production change was refused for its requester and approved by a second person. It has not been run against a live cloud account. The steps below say where a part is partial or missing.

Before you start

1. Connect the repository that holds your Terraform code. Open Apps → Repositories and choose Connect a repository. Polo verifies the repository and its protected branch. Under GitHub Actions and pull request permissions, list the Approved write paths Polo may change; without them it can only read.
2. Connect the cloud account on Infrastructure. See Connect a cloud account.
3. Create an agent from the Infrastructure agent template with Read source, Edit source and Run approved checks switched on, the tool to publish a draft pull request, and a Terraform skill for the stack. See Add Terraform to an agent.
4. Add what the team knows. Runbooks and conventions under Apps → Knowledge are read before the work starts. See Knowledge.

1. Assign the work

1. Open Home. In the Ask Polo box, choose the Infrastructure example or write your own request.
2. Describe what the service needs. Name the cloud account, the region and any constraints: Polo does not work these out by itself.
3. Open Repository, environment, and budget and choose the Repository, the Service and the Environment.
4. Say whether you want code only, or code and deployment.
5. Choose Assign to Polo.

The same request can arrive as a Jira or ClickUp ticket assigned to Polo. See Give work to Polo.

2. Polo inspects and asks

Polo reads the repository at a pinned revision, in its own workspace copy, along with the service catalog and the knowledge it may see. It looks at existing modules and conventions.

If something is missing that changes the work, Polo asks. The question appears on Approvals under Questions, and the task waits until someone answers.

3. Polo writes and validates the code

Polo writes the Terraform changes in the workspace copy. It runs terraform fmt and terraform validate offline, and repairs what fails.

At this point there is no plan made with real credentials. Polo plans only the head of the registered branch, so it cannot plan its own change before it is merged. There is also no cost estimate.

4. Review the change

Polo publishes the verified change and proposes a draft pull request. Publishing it is a change to GitHub, so it waits on Approvals like any other change.

1. Approve the draft pull request on Approvals.
2. Review the code in GitHub as you would a colleague’s.

If you asked for code only, the work stops here. The task reports the change, the checks that ran and what remains.

Marking the draft ready and merging it are separate steps. If you let Polo do them, each needs its own approval; otherwise merge it yourself.

5. Plan and approve the deployment

Once the change is on the branch, Polo plans the stack at the branch head and proposes applying exactly that plan.

1. Open Approvals. The request reads like “Apply the Terraform plan for checkout (production)”.
2. Review the saved plan: the commit, the changes, and when the plan expires.
3. Choose Approve and execute, or Reject change with a reason.

Under a production rule that requires a second person, the requester’s own approval is refused and another approver must decide. Set this under Settings → Approval rules.

6. Apply and verify

The runner applies the approved plan. Polo then verifies the result with a refreshed plan, which must show no changes, and a check of the state. The request and its result are recorded on the task.

7. Read the outcome

Open the task on Tasks. It shows what happened, the changes and what became of each, the evidence, the artifacts and the cost.

What is partial or missing

Part of the journey	State
Identifying the cloud account and constraints	Not automatic. Name them in the task.
A credentialed plan of an unmerged change	Not available. Plans are made at the branch head, after the merge.
Cost implications of the plan	Not available.
Draft pull request, then ready, merge, plan and apply as one flow	Each step works and was run locally; you approve each change separately.
Updating the originating ticket	Needs a separately approved Jira or ClickUp comment. Slack and Google Chat threads do not get an outcome summary for this journey.
OpenTofu, Pulumi, drift reports, import, state operations	Planned.

Related

• Add Terraform to an agent
• Approvals and guardrails
• Capabilities