MCP

Connect your agent to Wodby.

Set up Wodby’s Model Context Protocol (MCP) server in your coding agent. Choose its access, load workflow guidance, and try your first prompt.

Connect your agent Try an example

Start with your existing app

“Inspect this repository and plan its migration to Wodby. Don’t change anything yet.”

What to ask your agent to deliver

Map the app to compatible services and stacks
Identify data, configuration, and access gaps
Prepare staging checks and a cutover plan

An example request, not a completed migration. You review the plan before authorizing changes.

01 / Connect

Start in the agent
you already use.

Install your preferred agent and open your application repository. You’ll need a Wodby account and access to an organization to inspect or operate its resources.

During browser sign-in, check the organization and permissions you grant. Start with read access for assessment; authorize additional capabilities only when you need them.

Remote MCP endpoint

https://mcp.wodby.com/mcp

Using another client? It needs remote HTTP MCP support and a compatible authentication flow.

Authentication and setup reference

Connect Codex

Run these commands with Codex CLI installed, then complete the browser sign-in.

Terminal

codex mcp add wodby --url https://mcp.wodby.com/mcp
codex mcp login wodby

Open Codex in your application repository. Use /mcp to check that Wodby is connected.

Official Codex connection instructions

Using OpenRouter for models? Connect Wodby in your MCP-capable agent, not in the model-provider configuration. These examples follow the clients’ documented MCP setup; available features depend on your client version.

02 / Get oriented

Give your agent a first task.

Wodby’s tools provide platform access. Its skills explain how to plan, deploy, and troubleshoot. Your connected agent can load the relevant guidance on demand. No separate skill installation is required.

Start with a read-only connection check. If setup is incomplete, resolve that before asking the agent to deploy.

Browse skills and the optional download

First prompt

Use get_wodby_guidance to load wodby2-get-started. Check my Wodby connection and list the projects I can access. Do not create or change anything.

03 / Put it to work

A useful next step,
not a blank prompt.

Copy an example into your agent and supply your app, project, and environment when asked. Planning, staging, and production cutover are separate decisions.

Start here · read-only

Plan a migration

Understand what can move, what needs to change, and what is still unknown.

Plan a migration prompt

Use Wodby’s wodby2-migrate guidance to inspect this repository and plan its migration to Wodby. Identify required services, configuration changes, data transfer, likely downtime, and blockers. Do not create resources, connect to my current hosting, or change anything.

Expected result: A component mapping, staging plan, open decisions, and cutover checklist. This does not execute the migration.

After reviewing the plan

Deploy a staging copy

Rehearse the move before touching the application your customers use.

Deploy a staging copy prompt

Use the approved migration plan to prepare a staging copy on Wodby. Confirm the target and costs before creating resources. Keep production hosting, data, and DNS unchanged. Isolate workers, scheduled jobs, email, and webhooks. Ask before copying data.

Expected result: An isolated staging deployment, followed by task, runtime, and application checks. Missing permissions or setup steps are handed back to you.

Investigate · read-only

Debug a failing app

Give your agent deployment context and relevant logs without copying them between tools.

Debug a failing app prompt

Use Wodby’s troubleshooting guidance to investigate the failing service in my staging app. Check its latest deployment, task logs, and runtime status. If needed, watch the selected container’s logs briefly while I reproduce the issue. Do not restart, redeploy, or change the app.

Expected result: An evidence-backed diagnosis with relevant task or application logs, gaps in the evidence, and a proposed next step.

Plan first · approve separately

Prepare production cutover

Make the final move a deliberate decision with explicit recovery limits.

Prepare production cutover prompt

Prepare a production cutover checklist for the verified staging migration. Cover backups, final data synchronization, a write freeze if needed, DNS and TLS, workers, acceptance checks, and rollback after new writes. Identify manual steps. Do not execute the cutover.

Expected result: A reviewable sequence with owners, stop conditions, and rollback limits. Staging approval does not authorize production changes.

Have a Laravel app?

Ask the migration plan to include PHP extensions, database compatibility, queue workers, scheduled jobs, uploads, and release migrations. Preserve the existing app; don’t replace it with a starter project.

Moving WordPress or Drupal?

Include the database and uploaded files, plugin or module requirements, background jobs, and domain-dependent settings. Rehearse with an isolated copy before planning the final sync.

Keep the boundaries clear.

Connecting an agent is not permission to move production. Review the target and consequences before approving a change.

Your access still applies: Wodby operations use the granted organization, scopes, and your user permissions. Review your agent’s own approval settings too.
Repository access is separate: Your agent reads code through the access you give it. Wodby MCP does not automatically inspect your repository or connect to your current host.
Keep credentials out of chat: Use sign-in and supported integration setup. Plans should name required secrets, not include their values. Treat application logs as potentially sensitive.
Check the outcome: Follow task history and verify runtime and application behavior. Missing tools or permissions need a handoff; a successful task alone is not a healthy app.

Connect your agent Looking for APIs, SDKs, or CLI?