Writing a good request

What makes a good plan

Tell the agent:

• which project and which service (their name is enough, the agent finds the IDs);
• what you want to achieve, not how to do it;
• your limits: a budget, “without redeploying”, “don’t touch the database”;
• to prepare a plan: it doesn’t run anything anyway, but it will know it has to submit a plan for review.

Reading and understanding

• “Go through my projects and tell me which services are disabled.”
• “Read my API’s logs from the last hour and explain the errors.”
• “Why does the worker service in the shop project keep restarting? Look at its health and its logs.”
• “How much does the prod cluster cost me per month, and what weighs the most?”

Changing something

• “Add a Redis to the shop project, link it to the API, and prepare the plan.”
• “Add the variable MAIL_FROM=contact@example.com to the api service and prepare the deployment.”
• “Set the api service to 3 fixed replicas and prepare the plan.”
• “Add a task that runs php artisan backup:clean every night at 2 a.m.”

Launching an application from its repository

Open the agent in the repository folder and use the instruction the console suggests (Copy the instruction, in the service’s launch guide). The agent reads the Dockerfile, the docker-compose file and the .env.example, then prepares: the port, the variables, the databases to add and link, the scheduled tasks. See Deploy your code.

Pricing before building

• “How much would this project cost on Fransys: a Node API, a front end, PostgreSQL, Stable at Scaleway?”

The agent goes through Fransys’s estimate, with today’s catalogue: it doesn’t work out a price itself.

Undoing

• “Undo the last plan that ran on the shop project.”

The agent prepares an undo plan, which you review. See Rolling back.

After the request

The plan lands in Plans, To decide. Review the actions, especially those with a direct effect (deployment, deletion, machines), then Approve and run or Refuse, saying why: the agent will see the reason. See Plans.