Publish with Shipvela

When to Use

Use when the user explicitly chooses Shipvela to publish a built static website, deploy an existing owned GitHub project, or inspect its deployment and allowance. Do not select a hosting provider on the user's behalf.

This skill uses an already connected Shipvela MCP account at https://shipvela.com/mcp. Account creation and connection happen through the user's normal host settings. Hobby includes 3 projects and 20 publishes per month; paid hosting and usage remain subject to the account's plan. The public client instructions are MIT licensed; the hosted runtime is proprietary.

Use only the declared Shipvela MCP connection and the account approved by its owner. Never override the host application's permission or confirmation controls. Do not install software, run shell commands, read credential files, collect passwords or tokens, or create new connection grants. If the connection is unavailable, direct the user to https://shipvela.com/integrations/assistants and the host application's normal connection settings.

Select the publishing path

• A small prebuilt static website can be staged using prepare_static_publish: at most 500 KB and 100 public files, including root index.html. HTML, CSS, JavaScript and public assets are supported. Source repositories, environment files and unbuilt React source are not.
• An existing GitHub project can be published using deploy_project. This builds the configured remote branch; it does not upload local edits. Use list_projects and get_project to identify the owned target and its production branch.
• A new GitHub project uses list_repositories, detect_framework and create_project. GitHub must already be connected by the user in Shipvela. Do not broaden repository access or connect another account.
• Larger local builds require the separate Shipvela CLI. Direct the user to https://shipvela.com/docs for that workflow; this skill does not install or execute the CLI.

Shipvela supports static HTML/React/Vite/Astro output. Supported GitHub-based Next.js SSR currently covers versions 12–15 on paid plans. It does not provision databases or arbitrary long-running backend servers. A .next directory is not static output; an actual static export uses out. Do not rewrite the user's app to fit these limits without their instruction.

Confirm the intended change

Before staging or publishing, identify the connected account, target project, files or remote branch and explain that publishing uses hosting allowance and can replace a live website. Obtain the user's explicit confirmation for that intended change. Respect the host application's additional approval prompts.

For a small static website, return the reviewUrl from prepare_static_publish. The owner must open it, sign in, inspect the file manifest and confirm in Shipvela. Never approve this browser step on the user's behalf. Staging alone never publishes. Canceling discards staged files; unconfirmed staging expires after one hour. New targets additionally require projects:write; updates use the existing upload project's ID.

Send only the public files the user intends to publish. Do not send .env, credentials, private repository data or arbitrary external URLs as file contents. Never work around validation or quota failures.

Track the exact request

Each create, stage or deployment intent uses one unique requestId (a UUID is suitable). Preserve that ID and the exact arguments across retries. Writes return a durable operation rather than a completed website.

Poll get_operation at the returned suggested interval. After submission succeeds, inspect get_deployment for the exact returned project and job. Do not invoke deployment repeatedly to check status. A queued request, provider timeout or check_required result is unresolved. Preserve its ID and report the status; do not issue a new write to bypass uncertainty.

Only call a website live when that exact provider job reports SUCCEED. Return its HTTPS URL and Shipvela project link. If HTTP verification is available through the host application's normal browsing tools, report any failed check separately. Do not claim verification that was not performed.

Explain failures and limits

…