The AI assistant
The AI assistant
What the Chatbot can do, how to ask, and why it cannot break anything without your permission.
Chatbot in the sidebar is a chat that can actually do things. It is not a search engine with a nice voice: when you ask it about your server it connects to that server, runs commands, reads the output, and answers from what it found.
It starts every conversation in a mode where it is physically prevented from changing anything. Read the safety switch before you switch that off — it is short and it is the most important page here.
What you can ask it
Plain English is fine. Real examples:
- "My website shows 502. Please find out why."
- "What is using the disk on the shop server?"
- "Are there any security updates waiting? Which are urgent?"
- "Who logged into this server in the last week?"
- "Restart the app and check the site comes back."
- "Explain what this error means" — then paste the error.
- "Give me a PDF report of this server's health."
What it can reach
Only what you have connected, and only inside the project you have selected.
| It can | Detail |
|---|---|
| Run commands on your servers | Any server saved in this project |
| Use AWS | If the project is an AWS project |
| Drive Jenkins, Jira and Grafana | If connected |
| Read a MySQL database | Read-only, if connected |
| Search the web | For documentation and error messages |
| Write a PDF report | Reports |
It never sees your passwords, SSH keys or cloud keys. It asks our server to run a command, and it is given the output. See How we protect your credentials.
Starting a chat
Press New session and a panel asks "What do you want to do?":
| Tile | Use when |
|---|---|
| Fix my website or app | It is down, blank, slow or showing an error |
| Install or update software | nginx, Docker, PHP… with a backup and a way back |
| Check my server | A health, security and update review. Changes nothing |
| Browse ready-made tasks | All 40 tasks, searchable |
| Blank chat | Ask anything in your own words |
The first four are guided tasks: they ask a few questions, run a quick readiness check on the server, and then follow a known-good procedure. If a guided task matches what you need, use it — the answers are markedly better than a blank chat.
Getting a good answer
Say what you see, not what you think is wrong. "The site shows a white page since this morning" beats "I think nginx is broken" — the second sends it looking in one place.
Name the server if you have several. Or pick it from the server chips at the top of the chat.
Say when it started, and what changed. "It was fine until we deployed yesterday" is often the whole answer.
One thing at a time. A chat that fixes one problem well is better than one that half-fixes four.
Answer its questions. If it asks which domain, tell it. It is not being slow; it is avoiding acting on the wrong thing.
Reading its replies
Good answers end with three things: what was wrong, what I did, and what to do next. If you only get raw command output, ask "explain that in plain words" — it will.
The things around the chat box
| Control | What it is |
|---|---|
| Read / Execute | The safety switch. Read this |
| Auto-approve | Stops asking for each change. Destructive ones still ask |
| Model picker | Which AI to use. Models and credit |
| Credit meter | What this is costing. Reads "Your key" if you brought your own |
| Server chips | Which servers this chat may touch |
On a phone these live in a drawer, with the message box and chat history always within reach.
What it is not good at
- Judgement calls about your business. It will not know that Tuesday morning is your busiest hour unless you tell it — or write it in the server's notes.
- Anything it cannot see. Not connected means invisible.
- Very long conversations. A chat that has been running all day carries its whole history into every reply, which costs more and eventually hits a limit. Start a new chat per problem.
- Recovering lost data. If a database has lost rows, stop and get a person.