ceu.gg

# the help chat

One engine answers in both places. The widget in the panel and the bot in Discord run the same service, and the Next.js route in front of the widget is a proxy that pipes the reply through as it arrives.

• Replies stream over Server-Sent Events, and the same channel carries the status line the widget shows while a tool is running.
• Answers come from a curated set of markdown files about the platform, searched by keyword with heading matches weighted higher. There are no embeddings and no vector database; the corpus is small enough to load whole, so the common question never reaches a search at all.
• Every Discord channel has a mode - answer everything, answer only when mentioned, or stay out. Ticket channels get a greeting, and Sky keeps quiet when the person talking is staff.
• The bot runs on exactly one replica at a time, elected through a Postgres advisory lock. Losing the lock disconnects the gateway and another replica takes over.
• When it cannot solve something, escalate_to_human pings the team in that channel instead of letting the model improvise an answer.

# tool calling

The model can call 18 tools. None of them touch the database: each one is an HTTP call to the platform's own API carrying the JWT of the person in the conversation, so a tool call is authorised the same way a click in the panel is.

• Permissions come from ABAC, the same matrix the panel reads. Sky never holds a credential of its own.
• Reading is open to anyone signed in: communities, servers, live status, console output, files, backups, plan and balance.
• Writing - editing a config file, starting or stopping a server, running a console command, creating a backup - needs an active paid plan, and that check fails closed.
• Nothing destructive runs on the first call. The tool returns needsConfirmation, Sky has to ask, and only a second call with confirmed: true goes through.
• A reply gets at most six tool rounds, and the last round is served without tools, so it has to stop investigating and answer.

# diagnostics

When a server will not boot, the console is a wall of English stack traces. Diagnostics is a separate loop that reads the server and writes a report: what is wrong, the evidence for it, and the fixes as buttons.

• The model gets read-only tools and eight rounds. The prompt pushes it to ask for several files in one round, because rounds are the scarce thing.
• It finishes by calling submit_diagnosis: a summary in plain Portuguese, findings marked INFO, WARNING or CRITICAL, and proposed actions. If it never calls it, the run returns text and no actions.
• Every finding has to cite something it actually read - a log line, a config value, a filename. Without that it is a guess, and a guess sends the owner to change the wrong thing.
• The quota belongs to the server, not to the account clicking. It comes from that server's hosting plan, and a community with several admins would otherwise get a different limit depending on who asked.
• A limit of zero also means unavailable, which is how the feature gets switched on and off for the free tier from the admin panel without a deploy.
• A run that passes its cost ceiling stops and returns what it has. A partial report beats an open invoice.
• Tool names are rewritten into plain language before the report is stored. One real report reached a customer reading get_server retornou: "Não encontrei esse recurso".

# observability

Prometheus and Grafana on the cluster, OpenTelemetry inside the services: traces, metrics and logs across eight server-side instrumentations. Tracing is currently sampled off in production, because at this size it cost more CPU than the traces were returning.

# security on a free tier

A free tier is an open invitation. Mass server creation, arbitrary code execution and hostile file uploads all have to be barred.

• No executable uploads. Plugins, mods and datapacks arrive through the integrated CurseForge and Modrinth catalogue.
• Everything goes through the panel and the API. There is no shell, and no path from a game server to the host filesystem.
• Containers run non-root, with CPU and memory limits per pod.
• Permissions are ABAC throughout: a matrix the frontend reads from the API, never a hardcoded role check.

# still open

• Scheduling places servers by availability. There is no regional strategy yet - fine at this size, and it will not stay fine.
• Monitoring says network and memory become the first limiters as the platform grows, ahead of CPU.