@velixir/mcp
v0.7.0
Published
Deploy web apps in any language to Velixir (the European cloud) straight from your AI agent: point deploy at a directory for a live URL and claim link, then read logs to debug what you shipped.
Maintainers
Readme
@velixir/mcp
Deploy web apps in any language to velixir, the European cloud, straight from your AI agent. deploy points at a source directory, packs the code, builds it with no Dockerfile, and returns a live URL plus a claim link the human opens to keep the app on a free, card-free account. logs fetches the build and runtime logs, and access_logs the HTTP requests the app served, so the agent can debug what it shipped. No velixir account is needed.
Why
The agent generated a real backend. Now it has to run somewhere. velixir runs real apps in Node, Python, Go, Ruby, PHP, Java, Elixir, Rust, .NET, and more, with managed Postgres and Valkey, in the EU, with no egress fees. This server lets an agent one-shot deploy the app it just built, then hand the user a link to keep it.
Use it
Zero install, run with npx:
npx -y @velixir/mcpClaude Desktop / Claude Code
Add to your MCP config:
{
"mcpServers": {
"velixir": {
"command": "npx",
"args": ["-y", "@velixir/mcp"]
}
}
}Cursor / Cline / Windsurf
Point the editor's MCP settings at the same command (npx -y @velixir/mcp).
The deploy tool
| Input | Required | Description |
| --- | --- | --- |
| directory | yes | Absolute path to the app's source directory. |
| name | no | Short name for the app; becomes part of the URL. |
| language | no | node, python, go, ruby, php, java, elixir, rust, dotnet, deno, fsharp. Detected from the project files if omitted; pass it when the folder mixes languages. |
| port | no | Only if the app hard-codes a port instead of reading the PORT env var. |
It returns the live URL, a claim URL (give this to the user), when the claim window closes, a deployment ID (pass it to logs), and a status URL to poll.
node_modules, .git, build output, and caches are skipped automatically. Nixpacks reinstalls dependencies and builds from source.
The logs tool
Fetch build and runtime logs, so the agent can debug what it shipped: a failed build returns why it failed (a diagnosis when it's a known failure, and the part of the build log that broke), a running app returns its recent container output.
| Input | Required | Description |
| --- | --- | --- |
| deployment_id | one of the two | The deployment ID from the deploy response (unclaimed apps, no account needed). |
| app_id | one of the two | An app the user owns. Needs VELIXIR_API_KEY. |
| release | no | With app_id: which release's build, as v12, 12 or a release ID. Defaults to the newest. |
| tail | no | How many recent lines to fetch (default 200, max 1000). |
An unclaimed (agent-deployed) app is addressed by deployment ID. Once it's claimed it belongs to the owner's account; read it by app_id with an API key.
The access_logs tool
The HTTP requests an app served, newest first, with a summary of status codes and the slowest request: use it to check the app is getting traffic and to find failing requests.
| Input | Required | Description |
| --- | --- | --- |
| deployment_id | one of these | From the deploy response. Works until the user claims the app. No account needed. |
| app_id | one of these | An app the user owns. Needs VELIXIR_API_KEY. |
| status | no | 2xx, 3xx, 4xx, 5xx, errors, or a code like 404. |
| path | no | Only paths containing this text. |
| method | no | HTTP method, e.g. POST. |
| since_minutes | no | Only the last N minutes. |
| limit | no | How many requests (default 50, max 200). |
Once an app is claimed its access logs belong to the owner (they include visitors' IP addresses), so the deployment ID stops working for them; use app_id with an API key.
Rewind, Fork and Replay
Guardrails for an agent working on a live app. All of these need VELIXIR_API_KEY.
| Tool | What it does |
| --- | --- |
| replay_release | Tests a built release against the app's real recent GET/HEAD traffic. Two sealed copies of the app are made from the same moment, one on the live release and one on the new one, and every request goes to both. Poll replay_status for the verdict (clean, review or regressions) and the findings: new errors, status changes, changed responses, slower routes. Values that change on every request are ignored. |
| replay_status | A replay's progress and report. |
| rewind_plan | What the app would come back as at a moment, per part: code and config, each database (exact to the second), each cache and the files (nearest earlier snapshot). Changes nothing. |
| rewind | Builds a sealed preview of the app as it was at a moment, on its own URL. Leave parts out (code, config, databases, caches, volume, exclude) to rewind only what went wrong. |
| rewind_apply | Makes a ready preview live. The original databases and caches are set aside, untouched, for a few days (then deleted, with database backups kept), so it can be undone until then. Writes made in the preview become live data. Only call it after the user confirms. |
| rewind_undo | Back to the data, release, config and files from just before the rewind. Also repairs an apply that didn't finish. |
| rewind_delete_set_aside | Deletes the originals an applied rewind set aside, now, to stop paying for them. The rewind can't be undone afterwards. Agent keys need approval. |
| fork | A separate copy of the app as it was at a moment (default now), with its own data, sealed from the internet by default. For reproducing a bug or working on a safe copy of production. |
| fork_status / fork_discard | Progress of a fork or preview; delete it and its data copies. |
| approval_status | Whether a request waiting for the user's approval was approved (and ran), denied or expired. |
Copies carry the original's env vars, including live API keys, which is why they can't reach the internet unless you ask for an unsealed fork.
Webhooks
Get told the moment a deploy goes live or fails, a build fails, or an agent is waiting for approval. These need an account-wide VELIXIR_API_KEY of a team Owner or Admin.
| Tool | What it does |
| --- | --- |
| list_webhooks | The team's outgoing webhook endpoints, their format and events, and whether each is on. |
| create_webhook | Adds an endpoint: signed JSON (returns the signing secret once) or a Slack incoming webhook. Optionally only some events, or only one app. |
| test_webhook | Sends a webhook.test event now and reports how the endpoint answered. |
Use an agent key
Create VELIXIR_API_KEY as an agent key (velixir.net, API keys, "An AI agent"). Your agent can deploy, read logs, replay releases and make rewind previews and forks as normal, but anything that deletes or overwrites (applying or undoing a rewind, discarding a copy, and deleting apps, databases, caches, volumes or domains through the API) doesn't run: velixir records it and the tool tells the agent to send you a link. You approve or deny it on the Approvals tab of the API keys page, and you get an email too. Agent keys can't create or revoke API keys, so an agent can't give itself a key without approvals.
Config
| Env var | Default | Description |
| --- | --- | --- |
| VELIXIR_API_URL | https://velixir.net | Override for staging or self-host. |
| VELIXIR_API_KEY | (none) | Optional. Lets access_logs read apps the user owns, by app_id, and enables the Rewind, Fork and Replay tools. Create one at velixir.net under API keys, ideally an agent key (see above). |
Requirements
Node.js 18 or newer.
