Common questions, straight answers.

Versioner sits alongside your existing CI/CD pipelines — it does not replace them. You send deployment events to Versioner via the GitHub Action, CLI, or direct API call. Versioner records each event, evaluates any rules you have configured, and returns a verdict (clear or blocked) before your deployment proceeds. No code access is required — only the metadata you choose to send.

Most teams are up and running in under 30 minutes. Add an API key to your CI/CD secrets, drop in the GitHub Action or a CLI call, and you immediately start seeing deployment events in your dashboard. Rules, approvals, and templates can be layered on over time — you do not need to configure everything upfront.

No. Versioner never touches your source code, pull requests, or environment secrets. It only receives the metadata you explicitly send — typically: product name, version, target environment, and the outcome of the deployment. Everything is push-only from your side.

Versioner works with any platform that can make an HTTP request or run a shell command: GitHub Actions, GitLab CI, Jenkins, CircleCI, Buildkite, Bitbucket Pipelines, and custom scripts. The GitHub Action is the fastest path for GitHub-native teams. Everyone else can use the CLI or the REST API directly.

The same way a failed test suite does: a non-zero exit code. Your pipeline calls the Versioner CLI or GitHub Action at the point where a deployment would normally proceed. Versioner acts as a decision engine — it evaluates every rule you have configured, checks for required approvals, and returns a verdict. If the verdict is "blocked", the CLI exits with a non-zero code, the pipeline step fails, and the deployment never happens. This works across any CI/CD platform: GitHub Actions, GitLab CI, Jenkins, Buildkite, and others. Even on platforms like Vercel, a failed build step prevents the deployment from proceeding — Versioner plugs into that same mechanism. No special integration is required; it is just another step in your pipeline that can pass or fail.

A Deployment Request (DR) is a structured record of intent — similar to a pull request but for deploying. It carries the versions, target environments, required approvals, release notes, and optional pre/post steps. A Deployment Rule is an org-level policy that Versioner evaluates automatically on every deployment: schedule restrictions, environment flow requirements, DR mandates, or version approval gates. Rules run silently in the background; DRs are collaborative artifacts your team creates and signs off on.

When your deployments follow a repeatable process. If every production release needs the same approval roles, the same pre-deployment database migration step, and the same post-deployment smoke test, encoding that once as a template means every DR starts pre-configured — nobody has to remember the checklist. Templates are especially useful paired with the DR Required rule: you mandate that every deployment to production must have an open DR, and the template ensures that DR always includes the right gates. Without templates, that process lives in a wiki or in someone's head.

Report-only mode lets you evaluate rules and policies without actually blocking any deployments. Versioner runs the check, logs what would have been blocked, and lets the deployment proceed. It is the recommended starting point — you build confidence in your rule configuration before flipping the switch to enforcement. You can put individual rules in report-only mode or enable it org-wide.

Version Approvals let specific roles — QA, Security, a release manager — sign off on a version before it is eligible to reach certain environments. The sign-off travels with the version: once approved, the approval is recorded against that version across every deployment. On the Enforce plan, you can make Version Approvals a hard gate via a Deployment Rule.

Pre and post steps are ordered tasks attached to a Deployment Request that must be completed before the deployment can proceed (pre) or before the DR can close (post). Common examples: run database migrations before deploying, execute smoke tests after. Each step is logged with who completed it and when, creating a clear audit trail.

Yes. Versioner is deployment-type agnostic. If you can make an API call or run a shell command, you can track it: infrastructure changes, database migrations, ML model promotions, configuration updates, EMR cluster launches, notebook runs. The environment state grid will reflect whatever you send, giving you a single view across all your operational changes.

Versioner ships an MCP (Model Context Protocol) server that lets AI coding tools — Claude Code, Cursor, Windsurf — query live deployment state and take deployment actions directly from your editor. On the Observe plan, MCP read access is free: ask your AI assistant what version is in staging and get a live answer. On the Enforce plan, AI agents can also create Deployment Requests and run preflight readiness checks, making your AI tools deployment-aware.

Yes. The Observe tier — up to 15 users, 15 products, 5 environments, 90-day history, and MCP read access — is free with no time limit and no credit card required. It is not a trial. "Forever" means forever.

The 30-day trial gives you full access to every feature across all paid plans, including Deployment Rules, DR Templates, pre/post steps, sequential ordering, full MCP access, and advisory preflight. No credit card is required to start. At the end of the trial you choose a plan — or you stay on the free Observe tier.

When the trial ends, your account moves to the Observe tier by default — no data is deleted, and deployment history is preserved. If you were using paid features (Deployment Requests, Rules, etc.) they become read-only until you select a paid plan. You will receive advance notice before the trial expires.

Yes. You can upgrade or downgrade at any time. Upgrades take effect immediately; downgrades take effect at the end of the current billing period. If you are on an annual plan, contact us and we will sort it out.

Yes. Reach out at sales@versioner.io with a brief description of your organization and we will work something out.

Only what you explicitly send: deployment metadata (product name, version string, target environment, timestamp, outcome, and any custom fields you include). Versioner never requests access to your source code, pull requests, secrets, or cloud infrastructure. You control exactly what flows in.

SOC 2 certification is on our roadmap. In the meantime, Versioner is built on AWS infrastructure with encryption at rest and in transit, no secret storage, and a zero-trust data model by design. Enterprise customers can request our current security posture documentation.

Not currently. Versioner is a hosted SaaS product. Self-hosting is a common Enterprise request and something we evaluate regularly. If it is a hard requirement for your organization, reach out at sales@versioner.io — we want to understand your constraints.

SSO (SAML / OIDC) is available on the Enterprise plan. If you are on a lower tier and SSO is a blocker, contact us — we can discuss options.