# Glossary --- Plain-language definitions of the core Deployment.io terms — outcome, Task, job, runner, environment, MCP server, and more. ### Approval gate A checkpoint that pauses a production deployment until a human signs off — from Slack or the dashboard. Platform approval policies are configurable per agent key. For Managed delivery, the designated customer reviewer approves production through the agreed release process. ### Environment An isolated deployment target — for example dev, staging, or production — each optionally in its own cloud account. Agents deploy to a specific environment, and you can switch between them with a single MCP call. ### First Outcome Sprint A scoped first engagement into Managed: one outcome planned, built, verified, and deployed to your cloud. Scope, acceptance criteria, timeline, price, and payment terms are agreed in the proposal before delivery begins. ### Job The billing unit. A job is any AI, CI/CD, or infrastructure task that runs on your cloud or ours — a Task, a deploy, a log fetch, a custom-domain setup, a response-header change, or AI-driven log debugging. A Task counts as one job. ### Managed The done-for-you tier: the Deployment.io team operates the platform for you, turning a backlog of outcomes into deployments on your cloud. Priced as a custom retainer. (On the self-serve tiers — Free and Team — you operate the platform yourself.) ### MCP server Deployment.io's native Model Context Protocol surface. It gives coding agents real deploy actions to call — `deploy_static_site`, `deploy_web_service`, `get_deployment_logs`, `get_approval_status`, and more — so the agent executes actual deployments, not chat. ### Outcome A result you want shipped — a feature, a migration, a fix — rather than a single edit or ticket. You describe an outcome, and the planning agent turns it into ordered work across the right repos. ### Planning agent The agent that reads your repos and architecture, writes a spec, and decomposes an outcome into ordered Tasks across the right repos. ### Preview A live preview of a static site a Task changes, stood up on your cloud while the agent works. The pull request lists each preview's URL. See [Previews](/docs/tasks/previews/#previews). ### Preview configuration The variables and secret files previews built by Deployment.io use, set in **Org Settings → Agents → QA**. Add only values meant for previews, never staging or production secrets. See [Preview configuration](/docs/tasks/previews/#preview-configuration). ### Review A second AI agent run that checks a Task's change — including its security, its correctness, and whether it does what the description asks — before the pull request opens. See [Review](/docs/tasks/review/#review). ### Runner The open-source component that runs inside your own cloud and does the work that touches your infrastructure — checking out code, building, and deploying. The runner uses permissions configured in your cloud account. Job state, logs, and metadata return to the control plane, and agents send model requests to the configured provider. You can audit or fork the runner. ### Self-serve Using Deployment.io as a platform you operate yourself (the Free and Team plans): describe an outcome and the agents ship it, or point your own coding agent at the MCP server. Contrast with Managed, where our team operates it for you. ### Self-verification The step where an agent runs your build and tests in its own sandbox and only marks a Task done when they pass — so you review changes that already work instead of diffs you hope work. ### Skill An open-source, SKILL.md-compliant bundle (MIT) that teaches your coding agent Deployment.io's deploy playbook — framework-to-output mappings, port and health-check discovery, and the approval flow. It pairs with the MCP server. ### Step An optional sub-unit of work within a Task. Multi-Step Tasks break a Task into ordered Steps, and each Step counts as one job. Most Tasks use zero user-defined Steps, so they're a single job. ### Task The unit of execution. The planning agent decomposes an outcome into one or more Tasks across the right repos; each Task runs in an isolated, sandboxed container, writes and commits code, and is verified before it's marked done. One Task is one job, and Tasks can declare dependencies so multi-repo changes ship in the right order. --- Source: https://deployment.io/docs/introduction/glossary/