# Devopness documentation authoring guidelines Devopness docs are used by people deploying infrastructure and apps, and by AI agents connected through the Devopness MCP server. This guide is for human contributors, including: * developers * team leads * founders Use this guide for writing style, structure, and clarity across `docs/docs/*`. It helps keep docs clear for readers and easy to process by documentation tools and AI agents. ## Scope [#scope] * Apply this guide to all files under `docs/docs/` * Goal: clear pages, predictable structure, and outcomes that work in the web app, in MCP sessions, and in automation scripts ## 0) Audiences and interface priority [#0-audiences-and-interface-priority] Devopness has two main surfaces: the web app and MCP. Organize docs around the task the reader wants to complete, not around Devopness internals. Write each operation page for three readers: | Reader | Primary sections | What they need | | --------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------- | | Human using in-app `?` help | Goal, What you need, follow-up section, Common issues | Field meaning and decisions, not navigation to the form they are already on | | MCP-connected agent | Goal, Using Devopness MCP, Verify, What you need | Example prompts, scope, and success signals | | Website visitor browsing the docs | Goal, What you need, Using Devopness MCP, Verify, What to do next | A clear path from the task to the next step | **Documentation priority (not product stack priority):** 1. **Goal + Verify** — every operation page 2. **What you need** — form-backed operations and deploy dialogs 3. **Using Devopness MCP** — example prompts and expected outcomes 4. **Follow-up section** — use the heading that matches the action (see operation types below) 5. **What to do next** — end the page here when follow-up actions exist If an operation is **API-only today** (some webhooks and automation flows), say so upfront and link to the API reference site. Do not invent UI steps. ## 1) Document structure [#1-document-structure] ### Index pages (`index.md`) [#index-pages-indexmd] * Keep index pages conceptual * Start with a brief introductory paragraph that explains the concept in plain language * Make them complete enough for a first-time visitor: what the concept is, when to use it, and how it relates * Do not make concept pages too short: include a brief introduction plus 2 to 4 bullets that add context, examples, and practical use cases * Recommended sections: * About * Who this is for * Why this exists * Relationship to other concepts * Start here / Next * Do not use procedural `Goal`, `Steps`, or `Common issues` on index pages ### Operation pages (`add-*`, `edit-*`, `list-*`, `view-*`, `archive-*`, `deploy-*`, etc.) [#operation-pages-add--edit--list--view--archive--deploy--etc] * Keep operation pages outcome-driven * Use one follow-up heading that matches the action. Do not use `## After you save` on deploy, list, or view pages * Keep this section order on every operation page: ```markdown ## Goal ## Prerequisites (when permission or scope matters) ## What you need (or ## Deploy options on deploy pages) (or ## What you see on list/view pages) ## Using Devopness MCP (or a note when MCP is not available) ## After you save (add/edit only) ## Verify ## After deploy (deploy only) ## Common issues ## What to do next (last section when follow-up links exist) ``` Omit sections that do not apply to the operation type. * Group content by decision and outcome first, not by UI position * Do not open with numbered navigation steps when the doc is linked from the matching form * In `## What you need`, say what the reader needs to provide or choose in order to complete the action ### Deploy pages [#deploy-pages] * Keep `## Verify` tied to observable success, such as completed actions, reachable apps, or updated deployment history * Keep `## Common issues` anchored to user-visible symptoms, such as a specific landing page or a failed action step * Keep `## After deploy` when the action naturally leads to a next step, such as adding a virtual host or redeploying after config changes * Keep any concrete product symptom that users will recognize in the UI or logs * In follow-up sections, choose one style per line: either a task bullet or a short explanatory note, not both * When a next step needs a doc link, keep the bullet itself simple and put the link in a separate sentence or note if needed * Avoid generic page-menu headings like `Details`, `MCP`, and `Next` when a more descriptive phrase fits ### What to do next [#what-to-do-next] * Use `## What to do next` for practical follow-up use cases that help readers avoid common mistakes or choose the right next step * Keep it short and concrete * Do not repeat the core `What you need`, `Examples`, `Verify`, or `Common issues` sections ### List and view pages [#list-and-view-pages] * Use the same heading set where possible * Use `## What you see` or `## What you can change` for the main content, then explain what the user sees or can change inside that section ## 2) Intro and frontmatter behavior [#2-intro-and-frontmatter-behavior] * Do not add `intro` in frontmatter. Write page context in the markdown body * `index.md`: use the first paragraph for one conceptual sentence * Operation pages: use the first paragraph to state the outcome of the action * Keep one clear meaning for each core concept: * **organization:** top-level workspace for one company, legal entity, or client portfolio * **project:** groups environments and resources for one product or client inside an organization * **environment:** separate infrastructure setup inside a project (own servers, applications, credentials, pipelines, files, and deploy settings). Names like Development, Staging, and Production are common; dev might use one or two servers while production uses many servers, load balancers, or serverless infrastructure. Deploy to dev first, then promote stable work to staging and production * **application:** one git repository (or one folder in a monorepo) connected to one environment, with its own build and deploy settings * team * role * permission * etc ### Words for "environment" [#words-for-environment] Prefer plain phrases that work for non-native English readers: * **Good:** separate infrastructure setup, isolated space, separate copy of infrastructure, fully independent * **Avoid:** boundary (abstract), container (conflicts with Docker in DevOps docs) Use **stage** only when talking about release flow (dev → staging → production), not as the definition of environment. Optional machine-parseable frontmatter: | Field | Purpose | Example | | ---------------------- | ---------------------------- | -------------------- | | `resource_type` | Canonical Devopness resource | `application` | | `operation` | CRUD or domain verb | `add`, `deploy` | | `required_permissions` | RBAC gate | `application:deploy` | ## 3) Voice and first-time clarity [#3-voice-and-first-time-clarity] * Lead with a plain-language sentence a first-time reader understands before internal terms * Use **you** and concrete examples (repo names, branches, stacks) before words like build target or source tree * On index pages, include an ordered **path to success**, not only a flat link list * Use **Think of it like this** or a short analogy when a concept is new * Show stack variety in examples (Node, Python, PHP, Java, Ruby, Go, C#, React, Laravel, etc.) so readers see Devopness is not limited to one PaaS-style runtime * Separate **Using Devopness MCP** from form guidance so humans on the `?` icon do not feel the page is only for agents * Prefer encouraging, direct phrasing in **Verify**, such as "You are done when…" * Do not use filler openers such as "You are in the right place if…". State the outcome in one plain sentence instead ### Typical application flow [#typical-application-flow] Do not present **link server to application** as a required step before first deploy. Recent Devopness versions link servers automatically during first deploy when needed. Keep **link server to application** as an optional page for changing or adding deploy targets after deploy has started. Guide readers through: 1. Add server 2. Add application 3. Deploy 4. Then optionally branch by app type: * Public API or web app → (later) add a virtual host and SSL certificate * Private worker or batch job → daemon or cron job (no virtual host required) **Pagination (`links.previous` / `links.next`)** should follow that path for the first-deploy sequence: `organizations/add-organization` → `projects/add-project` → `environments/add-environment` → `credentials/add-credential` → `servers/add-server` → `applications/add-application` → `deploy-application` Do not route `add-file` or `add-variable` to `link-server-to-application` as the next step in that sequence. Place `link-server-to-application` outside the default pagination chain, or after `deploy-application` when the page is about changing servers. ## 4) Language rules [#4-language-rules] * Use clear verbs: set, create, add, configure, select, verify, confirm, save, deploy * Avoid abstract jargon and enterprise language * Use plain English and familiar words * Avoid awkward wording, overloaded terms, and phrases that sound unnatural in everyday English * Avoid product-jargon terms that the docs do not otherwise use; prefer the plain user-facing phrase `package manager file` and explain the subfolder when root directory matters * Use `access` for user-facing outcomes and `permission(s)` for RBAC rules * Avoid UI position phrases unless they are required by the product design * Examples: top bar, upper-right, lower-left * Keep button labels exactly as they appear in the UI when mentioning them * Prefer `deploy` when writing actions tied to release, rollout, or platform operations * Use `ship` only for high-level, product-level outcomes outside UI action language ## 5) Decision and clarity [#5-decision-and-clarity] * Lead with outcomes: * what people can do next * what changes after the action * what to check next * In `## Goal`, state the result of the action, not the waiting, clicking, or verification steps * Add decision support where needed: * when to start a new project * when to split environments * when to use one token type vs another * Keep examples concrete: * API, web app, worker, background queue, production flow * Explain the result before long detail ## 6) LLM-friendly format [#6-llm-friendly-format] * Keep sections predictable and clear. Agents and RAG chunk by H2 headings. * Prefer clarity over extreme brevity. Write enough detail so a newcomer can act without follow-up questions. * Keep sentences short and direct * Keep **Verify** on every operation page with a concrete success signal * Place **Verify** after the follow-up section on `add-*` and `edit-*` pages, and before **After deploy** on `deploy-*` pages * Place **Common issues** after **Verify** (and after **After deploy** on deploy pages) * End the page with **What to do next** when follow-up links exist. Do not place sections after it * Keep naming, meaning, and sequence consistent across sibling pages * On **Using Devopness MCP** sections, include a short lead-in like `Try these examples in Devopness MCP:` when it helps the reader * On `What you need` sections, map UI labels to plain-language descriptions when helpful * Do not put navigation-only steps at the top of pages used as in-app help ## 7) List style and punctuation [#7-list-style-and-punctuation] * For short bullet items and checklist items, skip the final period * Use a period only for full sentences with more than one clause * Keep list length short * Start every checklist item with action verbs when possible * Do not add trailing colons to Markdown headings (`## About:` is invalid style; use `## About`) * Use colons in prose only when they introduce examples, ranges, or key/value clauses, not as heading punctuation ### Dashes and hyphens [#dashes-and-hyphens] * **Hyphens (`-`)** join compound words: `long-running`, `first-time`, `single-stack` * **Colons (`:`)** introduce examples or lists after a complete clause: * Good: `One environment can host many applications: your API, frontend, worker` * Good: `**Application:** Devopness settings for one repo in one environment` * **Avoid em dashes (`—`)** glued to words without spaces. Readers can misread `applications—your` as one word * Prefer a colon, period, or parentheses instead of an em dash when adding an explanation or example * If you use an em dash, put spaces around it: `applications — your API, frontend` * In numbered steps, put the explanation after the link on a new phrase or use a colon, not an em dash: * Good: `1. Add an application: connect your repository to this environment` * Avoid: `1. Add an application — connect your repository` ## 8) Minimum checklist (every doc change) [#8-minimum-checklist-every-doc-change] * [ ] one clear outcome in the opening sentence * [ ] **Verify** with a concrete success signal, in the order defined for that operation type * [ ] **Using Devopness MCP** when the operation is available through MCP, or a brief note when MCP is not available * [ ] follow-up heading matches the operation type (`After you save`, `After deploy`, etc.) * [ ] **What you need** section on operation pages, not navigation steps * [ ] `required_permissions` in frontmatter when the operation is permission-gated * [ ] one **Common issues** section on operation pages * [ ] **What to do next** as the last section when follow-up links exist * [ ] no `intro` in frontmatter ## 9) What to include [#9-what-to-include] * Document outcomes and field decisions, not menu paths * For concept pages, keep enough context for first-time readers and discovery, including practical examples and decision signals * Add what changes after each action * Add one practical example for each major concept * Add MCP prompts that name scope: organization, project, environment, resource names ## 10) What to avoid [#10-what-to-avoid] * Avoid repeating API validation details already shown by the API or OpenAPI * Avoid long policy essays in setup guides * Avoid abstract terms without a concrete example * Avoid opening form help topics with "navigate to… click Add…" * Avoid long API blocks on MCP-primary pages. Link to the API reference site instead. ## 11) Canonical location [#11-canonical-location] * This file is the canonical guide for documentation writing * Keep `/docs/docs/README.md` for frontmatter, markdown, and metadata rules # Get started with Devopness ## About [#about] Devopness helps you deploy apps and provision cloud infrastructure from scratch in your own accounts on AWS, Azure, Google Cloud, DigitalOcean, Hetzner, and others: networks, subnets, static IPs, servers, Linux configuration, and deploys — without SSH for routine tasks. Unlike server and app management panels that only connect to servers you already have (Coolify, Dokploy, and similar), Devopness creates infrastructure in your cloud through the platform, not only apps on servers you connected manually. Self-hosted and serverless cloud services are supported too. You can use the [web app](https://app.devopness.com/), the API, or [MCP Servers](/mcp) when Devopness is connected to your AI agents. **One MCP server** to manage any cloud, any infrastructure, any Linux version, and any stack: C#, Docker, Go, HTML, Java, Node.js, PHP, Python, Ruby, TypeScript, and more. ## Why Devopness exists [#why-devopness-exists] Today many software teams: * Wait on a DevOps specialist, platform team, or contractor for servers, deploys, and small config changes * Use many tools: Terraform or Ansible for infrastructure, CI pipelines like Jenkins or GitHub Actions, and separate services for SSL and DNS * Struggle to move apps between cloud providers because each one has different consoles and deployment workflows * Rely on platforms like Vercel or Heroku that start simple but become expensive or hard to leave as apps grow * Write code faster with AI, but still wait too long to get that code running in production Devopness combines what is usually split across multiple tools into one platform: * Cloud infrastructure from scratch: networks, subnets, static IPs, servers, and Linux configuration (instead of Terraform and Ansible) * CI/CD and hosted PaaS: Jenkins, GitHub Actions, Vercel, Heroku, and similar platforms * Server and app management panels: Devopness replaces separate panels per stack with one platform for all stacks: * **PHP:** cPanel, Laravel Forge/Envoyer, Plesk, RunCloud, ServerPanel.app * **Python:** FastAPI Cloud, and similar stack-focused tools * **Ruby:** Cloud 66, Hatchbox, Kamal (popular in Rails, works for any stack) * **Self-hosted (bring your own server):** Coolify, Dokploy * One simpler workflow for any tech stack and any cloud provider, in accounts you control People and AI agents can work from the web app, API, or MCP on a laptop, phone, or tablet. Fine-grained, role-based permissions per environment let teammates deploy without direct cloud-console access, improving security and access control. This helps you deploy more often to infrastructure you control, without needing deep expertise in every cloud provider. ## What Devopness gives you [#what-devopness-gives-you] * Ship your apps to infrastructure you own, with more frequent and safer deploys * Trigger zero-downtime deploys automatically when you push to git * See deploy history and infrastructure changes in one place, even from mobile, without SSH or cloud console access * Manage servers and deploys from the web app, without manual CLI workflows for routine tasks * Run DevOps operations in natural language through MCP when connected to your AI agents ## How Devopness is organized [#how-devopness-is-organized] Think of it like this: * **Organization:** one company, legal entity, or client portfolio in Devopness, like `/@acme` * **Project:** one product or client inside that organization * **Environment:** a separate infrastructure setup inside a project (its own servers, applications, credentials, and deploy settings). Names like `Development`, `Staging`, and `Production` are common * **Application:** one git repository (or one folder in a monorepo) connected to one environment Read more in [Organizations](/organizations), [Projects](/projects), and [Environments](/environments). ## Who this is for [#who-this-is-for] * Developers who ship apps, side projects, and cloud infrastructure * Team leads who want to simplify deploy workflows, speed up releases, and cut down on complex tooling * Founders and solo builders deploying from day one on cloud infrastructure they control * Freelancers and agencies who need fast deploys and separate client infrastructure at an affordable cost ## Where to start [#where-to-start] * [Create an account and sign in](https://app.devopness.com/). It is free, and no credit card is required. * Follow the **Getting started** section in the sidebar for the first-setup path from organization creation through creating a server and deploying your application * Watch walkthroughs on the [Devopness YouTube channel](https://www.youtube.com/@devopness) ## Get help [#get-help] If you need help, contact us on [GitHub](https://github.com/devopness/devopness/discussions) or join our [Discord](https://devopness.com/discord/). ## Report a vulnerability [#report-a-vulnerability] If you found a vulnerability in our product, please follow the guide [Reporting a Security Vulnerability](/security/reporting-a-security-vulnerability). # Actions Devopness creates an “action” every time you need to run a pipeline to perform single-step or multi-step operations on resources in your project environments. ## What are actions and action steps? [#what-are-actions-and-action-steps] An “action” is the execution of a pipeline. As in our daily routine of managing software projects we need to “take an action” to fix or improve something, that’s exactly what Devopness does for you and your team: * Devopness executes actions in an automated, predictable and reliable way, so your team can get repetitive tasks done without manual work Each step in a pipeline becomes an action step, that is then executed by Devopness according to how a pipeline was configured at that point in time. For your convenience, each action step output log is made available for you in Devopness action details view. # List Actions Learn how to view all actions executed in an environment and navigate to their details. 1. On Devopness, navigate to a project then select an environment 2. On the upper-right corner, click `ACTIONS` to see a list of all actions created in the current environment 3. Use the filters and search to narrow down actions by status, resource, or operation 4. Click the link in the `ACTION` column to open the action’s details view 5. In the details view you can inspect step-by-step logs and metadata # View details of an Action In this section you will learn how to find and understand details of a Devopness action You can access details of all actions executed in an environment to which you have access. 1. On Devopness, navigate to a project then select an environment 2. On the upper-right corner, click `ACTIONS` to see a list of all actions created in the current environment 3. In the list of actions, find the action you want to inspect and click the link in the `ACTION` column > You will be redirected to the action details view 4. In the action details view, the header displays: * `Status` * `Status reason`: a detailed explanation of why the action is in the current `Status` * The resource type (e.g.: `Application`, `Server`, `Service`, ...) to which the action was created * The operation being executed for that resource type (e.g.: `Deploy`, `Start`, `Stop`, ...) * The name of the environment in which that action was created * The start time * The user, or automated webhook, who triggered the action 5. An action can have one or more targets. Find a target/server and the action step you want to inspect and click `LOGS` 6. A text area will be displayed containing the output log of the action step execution # Add an Application Connect a git repository to this environment so Devopness can build and deploy it. ## Goal [#goal] Add the application before you deploy it. ## Prerequisites [#prerequisites] * You can create applications in this environment (`application:create`) * The target project and environment are already selected * A [credential](/docs/credentials/add-credential) that can read the repository on your git host ## What you need [#what-you-need] ### Source provider [#source-provider] The git host where the repository lives, such as GitHub, GitLab, or Bitbucket. It must match the host used by the credential. ### Credential [#credential] The OAuth token or access token Devopness uses to clone and read the repository. If the list is empty, [create a credential](/docs/credentials/add-credential) first. ### Repository [#repository] The repository name in `owner/name` format, for example `acme/api`. If the code lives inside a monorepo, set **Root directory** to the folder you want Devopness to build. ### Name [#name] The short name for this application in the environment. This is the name shown in lists and deploy logs. ### Programming language, framework, and engine version [#programming-language-framework-and-engine-version] The stack Devopness uses to choose default pipeline steps and runtime settings. Examples: Laravel, Django, FastAPI, Spring Boot, Rails, ASP.NET, Express. ### Root directory [#root-directory] The folder inside the repository that contains the package manager file for this application, such as `package.json`, `composer.json`, `Gemfile`, `pom.xml`, or `pyproject.toml`. Use the subfolder where that file lives. Use `/` only when the file is at the repository root. ### Default branch [#default-branch] The branch Devopness uses when a deploy does not specify another ref (usually `main` or `master`). ### Install dependencies command / Build command [#install-dependencies-command--build-command] Optional overrides for how Devopness installs packages and builds artifacts during deploy. Leave the defaults unless your stack needs custom commands. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In project `acme-platform`, Production environment, add an application from GitHub repo `acme/api` using my `acme-github` credential." * "List applications in Staging, then add the worker repo `acme/worker` with root directory `/apps/worker` and default branch `main`." * "Add a Laravel app from `acme/billing` to Production with the suggested PHP framework settings." ## After you save [#after-you-save] 1. [Deploy the application](/docs/applications/deploy-application). Devopness links a server on first deploy when needed 2. Then (optional): * **Background worker or scheduled job:** add a [daemon](/docs/daemons/add-daemon) or [cron job](/docs/cronjobs/add-cronjob) 3. Optional: customize the [deploy pipeline](/docs/pipelines/add-pipeline) or set up [deploy on git push](/docs/applications/deploy-application-using-incoming-hook) ## Verify [#verify] * The application appears in the environment list with the expected name and repository * The repository and credential match the git host you selected * The root directory points to the folder that contains your package manager file ## What to consider [#what-to-consider] ### Multiple applications in the same environment [#multiple-applications-in-the-same-environment] Add one application per service when that matches how you release code. This works when your API, frontend, worker, docs site, or SDK share the same environment but need different deploy settings. Create a new environment when you need separate infrastructure, data, access rules, or release cadence. ### Public vs private applications [#public-vs-private-applications] * **Public** (API, web app, marketing site): deploy * **Private** (queue worker, internal processor): deploy, then add a [daemon](/docs/daemons/add-daemon) or [cron job](/docs/cronjobs/add-cronjob) ### Redeploy after configuration changes [#redeploy-after-configuration-changes] If you change code or deploy settings, [deploy again](/docs/applications/deploy-application) so servers pick up the update. ## Common issues [#common-issues] * **No credential in the list:** [create one](/docs/credentials/add-credential) for the same source provider * **Repository not listed:** confirm the credential has access to that repo on the git host * **Deploy fails later at clone step:** check **Root directory** points to the folder with your package manager file * **You do not see Add Application:** confirm you have `application:create` for this environment ## What to do next [#what-to-do-next] * [Deploy Application](/docs/applications/deploy-application) # Deploy Application using an Incoming Hook Use an incoming hook when you want a git event or other external event to trigger an application deploy. This page is API-only today. Use the [Devopness API Reference](/api) and the webhook guide to create the hook that triggers a deploy pipeline. ## Goal [#goal] Trigger an application deploy when an external event reaches Devopness. ## Prerequisites [#prerequisites] * The application already exists * The deploy pipeline already exists * You know the pipeline ID * You have API access for webhook creation ## What you need [#what-you-need] * The pipeline ID for the deploy pipeline * The incoming webhook URL and secret from Devopness * The event in your source provider that should call the webhook * Access to your source provider's webhook settings ## How it works [#how-it-works] * Create the incoming webhook in Devopness * Copy the webhook URL and secret * Add the webhook to your source provider * Trigger the event * Verify the deploy action appears in Devopness ## Using Devopness MCP [#using-devopness-mcp] MCP is not available for creating incoming hooks. Use the [create incoming webhook](/docs/webhooks/create-incoming-webhook) guide instead. ## Find the pipeline ID [#find-the-pipeline-id] Use the pipeline ID for the deploy pipeline that should run when the event arrives. * Open the application pipeline details page and copy the ID from the URL, or use the API response if you already know the pipeline * If you have not created the pipeline yet, add one first from the application pipeline pages ## Provider setup [#provider-setup] Add the webhook in your git provider or automation tool. The provider must send the event to the incoming hook URL that Devopness gives you. ## After you save [#after-you-save] * The external source provider can call the incoming hook URL * The deploy pipeline can start from the incoming webhook event ## Verify [#verify] * A trigger event creates a new deploy action in the application history * The action log shows the incoming hook as the trigger source ## Common issues [#common-issues] * The webhook does not trigger anything: confirm the pipeline ID is correct * The hook request fails: check the webhook URL, secret, and source provider settings * The deploy starts but fails later: inspect the pipeline step logs ## What to do next [#what-to-do-next] * Review the [Deploy Application](/docs/applications/deploy-application) page * Configure an outgoing webhook if you want commit status updates back in your source provider # Deploy Application Run the deploy pipeline to build your code and release it to your servers. On first deploy, Devopness links a server automatically when one is needed. Each deploy creates a new timestamped release folder on the server, for example `~/acme-api/releases/2026-06-15 13:45:10`, and updates `~/acme-api/current` to point to the latest successful release. ## Goal [#goal] Run the deploy pipeline for an application branch, tag, or commit. ## Prerequisites [#prerequisites] * You can deploy applications in this environment (`application:deploy`) * The application already exists in the selected environment * Your [credential](/docs/credentials/add-credential) can still read the repository * **Root directory** and build settings match your repository layout ## Before you deploy [#before-you-deploy] * Confirm your deploy settings are correct for this environment ## Deploy options [#deploy-options] Use these fields when confirming a deploy in the web app. ### Branch, tag, or commit [#branch-tag-or-commit] The git ref to deploy. If you leave this blank, Devopness uses the application's **default branch**. ### Pipeline [#pipeline] The deploy pipeline to run. Use the default pipeline unless you maintain multiple pipelines for the same application. ### Target servers [#target-servers] Which servers receive this deploy. When omitted, Devopness uses the application's servers, including any linked automatically on a previous deploy. ### Deployment type [#deployment-type] How the release is applied, such as a standard deploy or rollback. Available values depend on your pipeline configuration. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Deploy the `acme-api` application in Production using branch `main`." * "Deploy `acme-web` to Staging and tell me when the deploy action completes." * "List recent deploy actions for `acme-worker` in Production and redeploy the last successful branch." ## Verify [#verify] * The deploy action reaches `completed`, not `failed` or stuck `pending` * The server has a new timestamped release folder under `~/application-name/releases/` * `~/application-name/current` points to the latest successful release * For a **private** worker: the process is running via your [daemon](/docs/daemons/add-daemon) or [cron job](/docs/cronjobs/add-cronjob) if you set one up * The deployment appears in history with the expected branch or commit ## After you deploy [#after-you-deploy] **Private worker or background job** * Add a [daemon](/docs/daemons/add-daemon) to keep the process running and restart it on failure * Add a [cron job](/docs/cronjobs/add-cronjob) for scheduled tasks from your application code **Any application** * If you changed code or deploy settings, deploy again so servers pick up the update * [Set up deploy on git push](/docs/applications/deploy-application-using-incoming-hook) when you want automatic releases ## What this looks like on your server [#what-this-looks-like-on-your-server] Devopness keeps each deploy as a separate release folder, so you can roll forward or roll back without overwriting the previous release. * `~/application-name/releases/` contains each deploy release * `~/application-name/current` points to the live release of the application * The current release is the last successful build that Devopness activated on the server ## Common issues [#common-issues] ### Deploy fails at `Get source from Git repository` [#deploy-fails-at-get-source-from-git-repository] * Confirm **Root directory** points to the folder with your package manager file (`package.json`, `composer.json`, `Gemfile`, `pom.xml`, etc.) * Confirm the credential is active and can read the repository * Read the failed action step logs ### Deploy keeps failing on the same step [#deploy-keeps-failing-on-the-same-step] * Read the logs for that pipeline step * Update the install dependencies or build command if your stack changed * Confirm repository access on the git host ### Deploy succeeds but the site shows "Configured by Devopness! 🚀" [#deploy-succeeds-but-the-site-shows-configured-by-devopness-] This usually applies to **public** apps that still need routing: * Configure routing so requests reach your deployed app output, then redeploy ## What to do next [#what-to-do-next] * [Add a daemon](/docs/daemons/add-daemon): for long-running background processes * [Deploy using an Incoming Hook](/docs/applications/deploy-application-using-incoming-hook): trigger deploys from git events # Edit an Application Change an application's repository, build settings, or branch when the source or deploy setup changes. ## Goal [#goal] Update application settings without creating a new application. ## Prerequisites [#prerequisites] * You can edit applications in this environment (`application:update`) * The project and environment are already selected * The application exists in that environment ## What you need [#what-you-need] Change only the fields that need an update. ### Repository or source location [#repository-or-source-location] The git repository, or the folder inside a monorepo, that Devopness should build. ### Source provider and credential [#source-provider-and-credential] The git host and credential that can read the source. ### Root directory [#root-directory] The folder that contains the package manager file for the application. Use a subfolder when the source lives inside a monorepo. ### Default branch [#default-branch] The branch Devopness uses when a deploy does not specify another ref. ### Install dependencies command / Build command [#install-dependencies-command--build-command] Custom commands only when the defaults no longer match your stack. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Update the `acme-api` application to use the `main` branch" * "Change the repository for `acme-web`" * "Update the build command for the application in Staging" ## After you save [#after-you-save] * The application stays the same in Devopness; only the updated fields change * Existing linked resources stay attached unless you change them * Deploy again if the changes affect runtime behavior ## Verify [#verify] * The application details show the updated settings * The repository, root directory, and commands match the new source layout ## Common issues [#common-issues] * You cannot save changes: confirm you still have edit permission * A field validation error appears: check the updated repository path or command text * The application still uses the old settings: confirm you saved the change in the correct environment ## What to do next [#what-to-do-next] * [View the application](/docs/applications/view-application) * [Deploy the application](/docs/applications/deploy-application) when the change affects runtime behavior # Applications An **application** connects one git repository (or one folder in a monorepo) to one environment, so Devopness knows what to build, how to deploy it, and where it runs. Examples: an API, web app, worker, or internal tool. Devopness supports Node, Python, PHP, Java, Ruby, Go, C#, and other stacks. ## Think of it like this [#think-of-it-like-this] * **Repository:** where your code lives on GitHub, GitLab, or Bitbucket * **Environment:** a separate infrastructure setup inside one project (its own servers, applications, credentials, files, and deploy settings) * **Application:** Devopness settings for one repository, or one folder in a monorepo, in one environment (branch, build commands, runtime) * **Deploy:** the pipeline that builds your code and releases it to your servers * **Files / variables:** configuration such as a `.env` file with environment variables for that environment * **Virtual host:** optional public URL for APIs and web apps * **Daemon or cron job:** optional long-running or scheduled processes for workers and background jobs ## About [#about] * One environment can host many applications: your API, frontend, worker, docs site, internal tools, and more * Each environment is fully isolated: its servers, applications, credentials, and configuration do not overlap with other environments in the same project * Infrastructure can differ per environment: dev on one or two servers, production on many servers behind a load balancer, or on serverless cloud resources * One application maps to the root directory of a repository, or to a specific folder in a monorepo when each service needs its own deploy settings * During deployment, Devopness links your application to the target servers you choose * Applications keep deploy settings, pipelines, files, and related resources together for each environment ## Who this is for [#who-this-is-for] * Developers who deploy web apps, APIs, workers, or internal tools on their own servers * Team leads who manage releases per environment * Anyone who uses the API or MCP to automate deploys ## Why this exists [#why-this-exists] Applications tell Devopness which codebase to build and deploy in which environment. You set the source once; Devopness runs the pipeline and places the release on your servers. ## Relationship to other concepts [#relationship-to-other-concepts] * **Projects** group related work for one product or client * **Environments** are separate infrastructure setups inside a project. Names like Development, Staging, and Production are common. Deploy to dev first, then move stable work to staging and production * **Servers** receive your deploys (Devopness assigns them on first deploy when needed) * **Pipelines** define build and deploy steps for your stack * **Files** store environment configuration such as `.env` * **Virtual hosts** expose a public API or web app on a domain or server IP * **Daemons and cron jobs** keep private or background workloads running without a public URL ## Practical example [#practical-example] A team adds three applications in one Production environment: * `acme/api`: an API in Node, Python, PHP, Java, Ruby, Go, C#, or another supported stack * `acme/web`: a frontend in React, Next.js, Vite, TanStack Router, or another static or SSR framework * `acme/worker`: a queue consumer or background job processor with no public URL They add configuration files (for example `.env` per application), deploy each one, add a [virtual host](/docs/virtual-hosts/add-virtual-host) for the API and web app, and use [daemons](/docs/daemons/add-daemon) or [cron jobs](/docs/cronjobs/add-cronjob) to run the worker. ## First deploy path [#first-deploy-path] If this is your first application in Devopness: 1. [Add an application](/docs/applications/add-application): connect your repository to this environment 2. Add [configuration files](/docs/files/add-file), for example a `.env` with environment variables 3. [Deploy](/docs/applications/deploy-application): build and release your code (Devopness links a server on first deploy when needed) 4. Then: * **Public API or web app:** [add a virtual host](/docs/virtual-hosts/add-virtual-host) * **Private worker or batch job:** add a [daemon](/docs/daemons/add-daemon) or [cron job](/docs/cronjobs/add-cronjob); no virtual host required ## Common questions [#common-questions] * **One repo or many applications?** One application per repo is common. Use separate applications with different root directories when one monorepo contains multiple services. Look for folders with `package.json`, `composer.json`, `Gemfile`, `pyproject.toml`, `Dockerfile`, or `docker-compose.yaml` * **Dev, staging, and production?** Use separate environments when infrastructure must stay isolated. Dev might run on one or two servers; production might use many servers, load balancers, or serverless targets. Deploy to dev first, then move stable work to staging and production * **Do I need a virtual host?** Only when the app should be reachable on the internet. Workers and internal tools usually do not need one ## Start here [#start-here] * [Add an application](/docs/applications/add-application) * [Deploy an application](/docs/applications/deploy-application) * [List applications](/docs/applications/list-applications) # Integrate Application deployments with your Continuous Integration (CI) workflows Use an outgoing hook when you want Devopness to report deploy progress back to your source provider or CI system. This page is API-only today. Use the [Devopness API Reference](/api) to create outgoing hooks that update commit status in your source provider. ## Goal [#goal] Keep source provider commit status in sync with application deploy actions. ## Prerequisites [#prerequisites] * The application already has a deploy pipeline * You know the pipeline ID * You have API access for webhook creation * You know the commit status format required by your source provider ## What you need [#what-you-need] * The pipeline ID for the deploy pipeline * The target URL that your source provider should call * The request headers required by the source provider * The request body shape required by the source provider ## How it works [#how-it-works] * Devopness emits action events for the deploy pipeline * Your outgoing hook sends a status update to the provider * The provider updates the commit status for the same commit ## Using Devopness MCP [#using-devopness-mcp] MCP is not available for creating outgoing hooks. Use the [create outgoing webhook](/docs/webhooks/create-outgoing-webhook) guide and the source provider API docs below: * [Bitbucket commit statuses](https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commit-statuses/#api-repositories-workspace-repo-slug-commit-commit-statuses-build-post) * [GitHub commit statuses](https://docs.github.com/en/rest/commits/statuses#create-a-commit-status) * [GitLab commit statuses](https://docs.gitlab.com/ee/api/commits.html#set-the-pipeline-status-of-a-commit) ## Minimal request [#minimal-request] Use the API reference and the outgoing webhook guide to fill in the provider-specific body. A minimal request looks like this: ```bash curl --request POST \ --url https://api.devopness.com/pipelines//hooks/outgoing \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ ... }' ``` ## After you save [#after-you-save] * The source provider can show deploy progress for the selected commit * The same context value should be reused so each status updates the same entry ## Find the pipeline ID [#find-the-pipeline-id] Use the pipeline ID for the deploy pipeline that emits the action events. * Open the application pipeline details page and copy the ID from the URL, or use the API response if you already know the pipeline * If you have not created the pipeline yet, add one first from the application pipeline pages ## Verify [#verify] * The source provider shows the expected commit status for the deploy action * The status links back to the Devopness action details page * The same commit status entry updates as the action moves through its states ## Common issues [#common-issues] * The status never updates: confirm the pipeline ID and hook URL are correct * The source provider rejects the request: confirm the headers and body match its API * Each status creates a new entry: reuse the same `context` value for every event ## What to do next [#what-to-do-next] * Create the matching [incoming hook](/docs/applications/deploy-application-using-incoming-hook) if you also want deploys to start from source control events * Review the [Outgoing webhook](/docs/webhooks/create-outgoing-webhook) guide for request details # Link a server to an application Choose which servers receive deploys for an application. On first deploy, Devopness usually links a server automatically. Use this page when you need to add servers, change targets, or set the destination explicitly. ## Goal [#goal] Update the server list for an application. ## What you need [#what-you-need] * Permission to update the application * The application selected in the correct environment * The server or servers that should receive deploys ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Link the `web-1` server to `acme-web`" * "Attach the production servers to `acme-api`" * "Link the staging server to the `acme-api` application" ## After you save [#after-you-save] * The linked server appears in the application server list * Future deploys can target the linked servers ## Verify [#verify] * The server appears in the linked servers list * A deploy uses the servers you expect ## Common issues [#common-issues] * The server does not appear in the list: confirm it belongs to the selected environment * You cannot link the server: confirm you have update permission for the application * The link disappears after refresh: confirm the save completed ## What to do next [#what-to-do-next] * [Deploy the application](/docs/applications/deploy-application) * [Add a virtual host](/docs/virtual-hosts/add-virtual-host) when the app needs a public URL * [Add a daemon](/docs/daemons/add-daemon) or [cron job](/docs/cronjobs/add-cronjob) for private or scheduled workloads # List Applications List applications in one environment. ## Goal [#goal] See which applications exist in the selected project and environment. ## What you need [#what-you-need] * The correct project and environment selected * Permission to read applications ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "List the applications in the Production environment of `acme-platform`" * "Show applications named `api` in Staging" * "List the applications in my current environment" ## What you see [#what-you-see] * Application names you can open * Search by name when the list is long ## Verify [#verify] * The list shows the environment you expected * The application names match what you need to manage ## Common issues [#common-issues] * The list is empty: confirm you selected the correct environment * An application is missing: confirm you have read access to that environment * Search returns no results: check the application name or switch environments ## What to do next [#what-to-do-next] * [View an application](/docs/applications/view-application) * [Deploy an application](/docs/applications/deploy-application) # View an Application Open one application to inspect its repository, deploy settings, and related resources. ## Goal [#goal] Check repository, pipeline, and deploy settings before you edit or deploy. ## What you need [#what-you-need] * The correct project and environment selected * Permission to read applications * The application name or list entry you want to open ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Show me the application `acme-api`" * "Open the application details for the Staging app named `acme-web`" * "Show the repository and deploy settings for `acme-web`" ## What you see [#what-you-see] * Repository details and deploy configuration * Tabs for pipelines, deployments, servers, files, variables, and virtual hosts * Settings that control how the application is built and released ## Verify [#verify] * The details page shows the application you expected * The repository and deploy settings match the current setup ## Common issues [#common-issues] * The application does not open: confirm you selected the correct environment * Details look stale: reopen the page after saving related changes * Related tabs are empty: confirm the application has the resources you expect ## What to do next [#what-to-do-next] * [Edit the application](/docs/applications/edit-application) when settings need to change * [Deploy the application](/docs/applications/deploy-application) when the configuration is ready # Add Amazon Web Services (AWS) Credential In order to allow Devopness to manage AWS resources on your behalf, IAM user security credentials have to be provided. > If you don't have access to an AWS account, you can create an account for free following the cloud provider specific guide [AWS Free Tier](https://aws.amazon.com/free/) 1. Log in to AWS console and access [AWS IAM](https://console.aws.amazon.com/iam/) AWS IAM Console 2. In the navigation pane on the left side, choose `Users` and then choose `Create user` Create new user 3. Type the user name for the new user and click `Next`. Tip: you might want to name the user as `devopness` to make it easier to track its activities User details 4. In the `Set Permissions` step click `Attach policies directly` Set permissions 5. Search and select the policies `AmazonEC2FullAccess` Set EC2 permission 6. and `IAMReadOnlyAccess` Set IAM permission 7. Follow the prompts then click `Create user` Create user 8. In the `Users` list, click the username link of the user you've just created List of users 9. Navigate to the `Security credentials` tab Security credentials tab 10. In this page, scroll down to the `Access keys` section and click `Create access key` Access key 11. Choose `Other` and click `Next` Create key 12. Give the key a description (Optional) and click 'Next' and click `Create access key` Description key 13. Copy the values of `Access key ID` and `Secret access key` Create user 14. To add the copied credentials to Devopness see [Add a Credential](/credentials/add-credential) # Add Microsoft Azure Credential In order to allow Devopness to manage Azure resources on your behalf, Service Principal credentials have to be provided. > If you don't have access to an Azure account, you can create an account for free following the cloud provider specific guide [Azure Free Services](https://azure.microsoft.com/en-us/pricing/free-services) 1. Log in to [Azure Portal](https://portal.azure.com/) 2. In the search bar, enter `App registrations` and select it 3. In the navigation bar, select `New registration` 4. Type the **Name** of the application * Tip: you might want to name the application as `devopness` to make it easier to track its activities 5. Under **Supported account types**, select `Accounts in this organizational directory only` 6. Under **Redirect URI**, select platform `Web` 7. Click `Register` 8. Copy the `Application (client) ID` as the value of `client_id` 9. Copy the `Directory (tenant) ID` as the value of `tenant_id` 10. In the navigation panel search bar on the left side, enter `Certificates & secrets` and select it 11. In the **Client secrets** tab, click `New client secret` 12. Type the **Description** of the client secret 13. Choose one option for **Expires** time 14. Click `Add` 15. Copy the `Value` of the client secret as the value of `client_secret` 16. In the search bar, enter `Subscriptions` and select it 17. Click on the `Subscription name` link of one of the subscriptions in the list 18. Copy the `Subscription ID` as the value of `subscription_id` 19. In the navigation panel on the left side, select `Access control (IAM)` 20. You can set permissions by using an Azure pre-defined role or creating a custom role with only the necessary permissions * Using a pre-defined role: 1. In the navigation bar, click on `Add` and select `Add role assignment` 2. In the **Role - Privileged administrator roles** tab, select `Contributor` role 3. Click `Next` 4. In the **Members** tab, click `Select members` 5. In the `Select members` search bar, type the name of **application** and select it 6. Click `Select` and click `Review + assign` 7. Ensure the **Role Contributor** and expected **application** are selected 8. Click `Review + assign` again * Using a custom role: 1. In the navigation bar, click on `Add` and select `Add custom role` 2. Type the **Custom role name** of the role * Tip: you might want to name the role as `devopness` to make it easier to identify 3. Under **Baseline permissions**, select `Start from scratch` 4. Click `Next` 5. In the navigation bar, click on `Add permissions` 6. Add each of the following **permissions** to the role:
Permissions - **Microsoft.Authorization/roleAssignments \{read\}** - **Microsoft.Authorization/roleDefinitions \{read\}** - **Microsoft.Compute/disks \{write\}** - **Microsoft.Compute/virtualMachines \{deallocate/action, delete, read, restart/action, start/action, write\}** - **Microsoft.Network/networkInterfaces \{delete, join/action, read, write\}** - **Microsoft.Network/networkSecurityGroups \{delete, join/action, read, write\}** - **Microsoft.Network/networkSecurityGroups/securityRules \{delete, read, write\}** - **Microsoft.Network/publicIPAddresses \{delete, join/action, read, write\}** - **Microsoft.Network/virtualNetworks \{delete, read, write\}** - **Microsoft.Network/virtualNetworks/subnets \{delete, join/action, read, write\}** - **Microsoft.Resources/subscriptions/resourceGroups \{read, write\}**
7. After adding the **permissions**, click `Review + create` in the navigation bar 8. Click `Create` 9. In **Access control (IAM)** page, in the navigation bar, click on `Add` and select `Add role assignment` 10. In the **Role - Job function roles** tab, search and select `your custom role` 11. Click `Next` 12. In the **Members** tab, click `Select members` 13. In the `Select members` search bar, type the name of **application** and select it 14. Click `Select` and click `Review + assign` 15. Ensure the expected **role** and **application** are selected 16. Click `Review + assign` again 21. To add the credential to Devopness see [Add a Credential](/credentials/add-credential) # Add a Credential Devopness allows you to manage multiple provider accounts from a single platform. Add Cloud Provider and Source Provider credentials to your environment to allow you and your team to provision, manage cloud infrastructure resources and deploy your applications with increased productivity. 1. On Devopness, navigate to a project and select an environment. 2. Find the `Credentials` card. 3. Click `View` on the `Credentials` card to see a list of existing `Credentials`. 4. In the upper-right corner of the list, click `ADD CREDENTIAL`. 5. Follow the prompts and click `CONFIRM` 6. In the `Credential` details view, the recently created `Credential` details can be seen ## Choose the right credential [#choose-the-right-credential] For team workflows, use a shared automation account instead of a personal account. This keeps access consistent and avoids tying deployments to one person. Example for a source provider (for example GitHub): 1. Create a dedicated user (for example `devopness` or `devopness-`) 2. Add it to your organization or repositories with the minimum permissions needed 3. Create a personal access token or SSH key for that user 4. Add the credential in Devopness Devopness also supports other source providers (for example GitLab or Bitbucket). For cloud providers, you can add multiple credentials as needed (for example AWS, Azure, GCP, DigitalOcean, Hetzner). Use different credentials if you want to keep access separate between projects or teams. # Add DigitalOcean Credential In order to allow Devopness to manage DigitalOcean resources on your behalf, API token has to be provided. > If you don't have access to a DigitalOcean account, you can create an account for free following the cloud provider specific guide [DigitalOcean Free Trial Offer](https://www.digitalocean.com/try/free-trial-offer) 1. Log in to [DigitalOcean Control Panel](https://cloud.digitalocean.com/) 2. In the navigation panel on the left side, click `API` 3. Below the title `Applications & API`, select the `Tokens` tab 4. In the `Tokens` tab, click `Generate New Token` 5. The `New personal access token` form will be displayed 6. Under `Token name`, click `Enter token name` field and type a name for the new token * Tip: you might want to name the token as `devopness` to make it easier to track its activities 7. Under `Expiration`, click the `Select token expiry` field and select one of the expiration options for when this token will become expired 8. Under `Select scopes`, ensure the `Write` option is checked * It’s critical that your token has the permission to create droplets, otherwise Devopness will be unable to add new Servers. 9. Click `Generate Token` 10. Copy the value of `token` * It will be the text prefixed with `dop_v1_` * Be sure to record your personal access token. For security purposes, it will not be shown again. 11. To add the copied credentials to Devopness see [Add a Credential](/credentials/add-credential) > For further details on how to create a DigitalOcean token, please refer to [DigitalOcean documentation](https://docs.digitalocean.com/reference/api/create-personal-access-token/) # Add Google Cloud Platform (GCP) Credential In order to allow Devopness to manage GCP resources on your behalf, Service Account key has to be provided. > If you don't have access to a GCP account, you can create an account for free following the cloud provider specific guide [Google Cloud Free Tier](https://cloud.google.com/free) ## Select your GCP project [#select-your-gcp-project] 1. Access a GCP project or create a new one: [https://console.cloud.google.com/project](https://console.cloud.google.com/project) > If you created a new project, a notification modal will appear showing your new project creation status. > Note: It might take a few seconds for the new project to be visible in the project list. > If your new project is not listed a few seconds after its creation, reload the console page. ## Enable GCP Compute Engine API [#enable-gcp-compute-engine-api] 2. Make sure `Compute Engine API` is enabled on the selected Project: * On GCP console, click on the dropdown menu and select [APIs and Services](https://console.cloud.google.com/apis/dashboard) * Make sure the correct project is selected in GCP console's header left side * Click on **Enable APIs and Services** on top of the page * On the Search box, enter "Compute Engine API" and select it from search results * If `Compute Engine API` is already activated, you will see the `Manage` button at the screen * Otherwise, click `Enable` button ## Enable GCP IAM API [#enable-gcp-iam-api] 3. Make sure `IAM API` is enabled on the selected Project: * On GCP console, click on the dropdown menu and select [APIs and Services](https://console.cloud.google.com/apis/dashboard) * Make sure the correct project is selected in GCP console's header left side * Click on **Enable APIs and Services** on top of the page * On the Search box, enter "IAM API" and select it from search results * If `IAM API` is already activated, you will see the `Manage` button at the screen * Otherwise, click `Enable` button ## Enable GCP Cloud Resource Manager API [#enable-gcp-cloud-resource-manager-api] 4. Make sure `Cloud Resource Manager API` is enabled on the selected Project: * On GCP console, click on the dropdown menu and select [APIs and Services](https://console.cloud.google.com/apis/dashboard) * Make sure the correct project is selected in GCP console's header left side * Click on **Enable APIs and Services** on top of the page * On the Search box, enter "Cloud Resource Manager API" and select it from search results * If `Cloud Resource Manager API` is already activated, you will see the `Manage` button at the screen * Otherwise, click `Enable` button ## Enable GCP Cloud Asset API [#enable-gcp-cloud-asset-api] 5. Make sure `Cloud Asset API` is enabled on the selected Project: * On GCP console, click on the dropdown menu and select [APIs and Services](https://console.cloud.google.com/apis/dashboard) * Make sure the correct project is selected in GCP console's header left side * Click on **Enable APIs and Services** on top of the page * On the Search box, enter "Cloud Asset API" and select it from search results * If `Cloud Asset API` is already activated, you will see the `Manage` button at the screen * Otherwise, click `Enable` button ## Set up a GCP service account [#set-up-a-gcp-service-account] 6. Go back to [projects console](https://console.cloud.google.com/project) 7. Having your project listed, click the three dot button on it and pick the `Settings` option 8. On the left side menu under `IAM & Admin`, select the `Service Accounts` option 9. Make sure a service account named as `-compute@developer.gserviceaccount.com` is listed 10. If you do not have a service account, [create a new one](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): * Click `+ CREATE SERVICE ACCOUNT` option below the search bar * Name your new service account * Click `DONE` 11. Having your service account listed, go to the `Actions` column, click the three dot menu on your service account and choose `Manage details` option 12. Copy your service account email to your clipboard ## Grant required IAM roles to the service account [#grant-required-iam-roles-to-the-service-account] \:::info Why are these permissions required? Devopness requires these roles to fully manage your infrastructure lifecycle on GCP.\ In addition to reading resources, it must be able to create, start, stop, and delete Compute Engine instances when provisioning or updating environments. The roles requested follow the principle of least privilege and avoid primitive roles like `Owner` or `Editor`. \::: ### Grant the Compute Engine Service Broker role [#grant-the-compute-engine-service-broker-role] 13. Below your service account name, go to the `PERMISSIONS` tab 14. In the permissions table, go to `VIEW BY ROLES` tab 15. Make sure your service account has the `Compute Engine Service Broker` role You may need to check the box labeled "Include Google-provided role grants" to see the `Compute Engine Service Broker` role in the list. 16. If the service account doesn't have the `Compute Engine Service Broker` role, set it: * Click `GRANT ACCESS` button * The `Grant access to "..."` form will be displayed * Under `Add Principals`, click the `New principals` field and paste the service account email you copied earlier * Under `Assign roles`, click the `Role` field and select the `Compute Engine Service Broker` option * Click `SAVE` ### Grant the Compute Instance Administrator role [#grant-the-compute-instance-administrator-role] 17. Below your service account name, go to the `PERMISSIONS` tab 18. In the permissions table, go to `VIEW BY ROLES` tab 19. Make sure your service account has the `Compute Instance Administrator (v1)` role 20. If the service account doesn't have the `Compute Instance Administrator (v1)` role, set it: * Click `GRANT ACCESS` button * The `Grant access to "..."` form will be displayed * Under `Add Principals`, click the `New principals` field and paste the service account email you copied earlier * Under `Assign roles`, click the `Role` field and select the `Compute Instance Administrator (v1)` option * Click `SAVE` ### Grant the Compute Security Administrator role [#grant-the-compute-security-administrator-role] 21. Below your service account name, go to the `PERMISSIONS` tab 22. In the permissions table, go to `VIEW BY ROLES` tab 23. Make sure your service account has the `Compute Security Administrator` role 24. If the service account doesn't have the `Compute Security Administrator` role, set it: * Click `GRANT ACCESS` button * The `Grant access to "..."` form will be displayed * Under `Add Principals`, click the `New principals` field and paste the service account email you copied earlier * Under `Assign roles`, click the `Role` field and select the `Compute Security Administrator` option * Click `SAVE` ### Grant the Reader role [#grant-the-reader-role] 25. Below your service account name, go to the `PERMISSIONS` tab 26. In the permissions table, go to `VIEW BY ROLES` tab 27. Make sure your service account has the `Reader` role 28. If the service account doesn't have the `Reader` role, set it: * Click `GRANT ACCESS` button * The `Grant access to "..."` form will be displayed * Under `Add Principals`, click the `New principals` field and paste the service account email you copied earlier * Under `Assign roles`, click the `Role` field * In the role selector, search for `Reader` or locate it under `Basic` roles * Click `SAVE` ### Grant the Service Account User role [#grant-the-service-account-user-role] 29. Below your service account name, go to the `PERMISSIONS` tab 30. In the permissions table, go to `VIEW BY ROLES` tab 31. Make sure your service account has the `Service Account User` role 32. If the service account doesn't have the `Service Account User` role, set it: * Click `GRANT ACCESS` button * The `Grant access to "..."` form will be displayed * Under `Add Principals`, click the `New principals` field and paste the service account email you copied earlier * Under `Assign roles`, click the `Role` field and select the `Service Account User` option * Click `SAVE` ## Generate a service account key [#generate-a-service-account-key] 33. On the left side menu under `IAM & Admin`, select the `Service Accounts` option 34. Go to the `Actions` column on your service account, click the three dot menu and choose `Manage keys` option 35. Add a new service account key: * Click `ADD KEY` button * Select `Create new key` option * Pick `JSON` key type * Click `CREATE` 36. A JSON file containing your service account credentials will be downloaded, copy its content to your clipboard ## Add credentials to Devopness [#add-credentials-to-devopness] 37. To add the copied credentials to Devopness, follow the guide [Add a Credential](/credentials/add-credential) # Add Hetzner Credential To allow Devopness to manage Hetzner Cloud resources on your behalf, an API token must be provided. > If you don't have access to a Hetzner account, you can create an account for free following the Hetzner Cloud [Sign Up](https://accounts.hetzner.com/signUp) page. 1. Log in to the [Hetzner Cloud Console](https://accounts.hetzner.com/login) 2. Access a Hetzner Cloud project or create a new one: [Projects page](https://console.hetzner.com/projects) > If you don't have a project, click on **New project**. > > Enter a name for the project and click **Add project**. > > Once the project is created, select it from the list to continue. > > **Note**: It might take a few seconds for the new project to be visible in the project list. If it does not appear, reload the console page. 3. In the left navigation panel, click `Security` 4. At the top menu, select the `API Tokens` tab 5. Click `Generate API Token` 6. In the `Generate API Token` form: * Enter a **description** for the token (e.g., `Devopness`) * Set permissions as `Read & Write` 7. Click `Generate API Token` 8. **Copy the API token** shown * **Important:** The token will not be shown again, so make sure to save it securely 9. To add the token to Devopness, follow the guide: [Add a Credential](/credentials/add-credential) > For more details, see the official Hetzner documentation on [Generating an API Token](https://docs.hetzner.com/cloud/api/getting-started/generating-api-token/) # Edit a Credential Sometimes you may need to update a credential name or rotate keys and secrets. Edit a credential to update its name and settings. 1. On Devopness, navigate to a project then select an environment 2. Find the `Credentials` card 3. Click `View` in the `Credentials` card to see a list of existing `Credentials` 4. In the list of credentials, find the credential you want to edit and click the `NAME` of the credential 5. On the upper-right corner of the credential details view, click `EDIT` 6. Follow the prompts then click `CONFIRM` 7. In the `Credential` details view, the recently updated `Credential` details can be seen # Get a Credential’s Status Get a Credential's Status to validate if a credential is still active and remains accepted by its provider. 1. On Devopness, navigate to a project then select an environment 2. Find the `Credentials` card 3. Click the `View` in the `Credentials` card to see a list of existing `Credentials` 4. In the list of credentials, find the credential you want to inspect and click the `NAME` of the credential 5. On the upper-right corner of the credential details view click `ACTIONS` 6. Use the drop-down menu to choose `Get Status` 7. Wait for the `credential:get-status` action to be completed 8. Check the action logs to see the credential's current status # Credentials In this section you will learn how to add cloud provider and source provider credentials to an environment, allowing you and your team to use Devopness to provision and manage cloud resources and deploy applications securely. # List Credentials View the list of credentials linked to a project environment. 1. On Devopness, navigate to a project and select an environment. 2. On the `Environment` page, click the **Credentials** card or click in `VIEW_ALL` button in card. * The list of existing credentials for this environment will be displayed, showing the credential's name, Provider Service, and Provider Type. # Remove a Credential Learn how to remove a credential when it's no longer needed In case you need to rotate credential keys, you can edit a credential instead of removing a credential and create a new one. To edit a credential, follow the guide [Edit a Credential](/credentials/edit-credential) If you are really sure you want to remove a credential, that cannot be done if the credential to be removed is currently in use by any environment resource. To remove a credential that is currently in use you should edit each resource using that credential to use another credential. 1. On Devopness, navigate to a project and select an environment. 2. Find the `Credentials` card. 3. Click `View` on the `Credentials` card to see a list of existing `Credentials`. 4. In the list of credentials, find the credential you want to remove and click the `NAME` of the credential 5. On the upper-right corner of the credential details view click `REMOVE` 6. Follow the prompts then click `REMOVE` 7. In the list of credentials, the recently removed `Credential` will be gone # View Credentials View details of a credential linked to a project environment. 1. On Devopness, navigate to a project and select an environment. 2. On the `Environment` page, click a credential item in **Credentials** card or click the name of the credential in the list of credentials * The details of the existing credentials for this environment will be displayed, showing the credential's name, Provider Service and Provider Type, Last Action Status, Created At, Updated At, and Created By. * On this page, you will also see the linked Pipelines and where the credential is used. # Add a Cron Job Add a cron job to run a recurring task. ## Goal [#goal] Automate a schedule-based operation safely from the UI. ## Steps [#steps] 1. Open the environment where the job should run 2. Open the `Cron Jobs` card 3. Click `View` 4. Click `ADD CRON JOB` 5. Set name, schedule, and command 6. Save ## Expected result [#expected-result] * The new cron job appears in the cron jobs list * The schedule starts according to the defined interval ## Common issues [#common-issues] * Missing permissions for cron jobs * Invalid cron expression * Job command references unavailable resource # Edit a Cron Job Change schedule, command, or metadata for one cron job. ## Goal [#goal] Adjust automation behavior without recreating the job. ## Steps [#steps] 1. Open the environment with the cron job 2. Open `Cron Jobs` 3. Open the target cron job 4. Click `EDIT` 5. Update settings and confirm ## Expected result [#expected-result] * The cron job reflects the new settings * Next executions follow the updated schedule ## Common issues [#common-issues] * You do not see edit action: confirm `cronjob:update` permission * Schedule parse error: verify the cron expression # Cron Jobs ## About [#about] Cron jobs let you automate recurring actions for both applications and servers. Use cron jobs in Devopness to schedule routine work like sending notifications, running maintenance scripts, cleaning up old files, and refreshing app or server resources. You can configure, monitor, and maintain all your scheduled jobs from one place. # Remove a Cron Job Remove a cron job when you no longer need scheduled execution. ## Goal [#goal] Stop and delete a recurring automation cleanly. ## Steps [#steps] 1. Open the environment with the cron job 2. Open `Cron Jobs` 3. Open the cron job to remove 4. Click `REMOVE` 5. Confirm `REMOVE CRON JOB` ## Expected result [#expected-result] * The cron job disappears from the list * No new executions will be scheduled from this job ## Common issues [#common-issues] * You cannot remove the job: confirm delete permissions * Removal is blocked because of background state # Add a Daemon Add a Daemon to keep a program alive, always running with the number of configured processes. A daemon run as a background process and can restart the program when it fails or its code/command line is modified. 1. On Devopness, navigate to a project, then select an environment 2. Find the `Daemons` card 3. Click `View` in the `Daemons` card to see a list of existing `Daemons` 4. On the upper-right corner of the list, click `ADD DAEMON` 5. Follow the prompts then click `CONFIRM` 6. In the `Daemon` details view, the recently created `Daemon` details can be seen # Edit a Daemon Edit a Daemon to update the application, settings, command, or other configurations of an existing Daemon. 1. On Devopness, navigate to a project, then select an environment 2. Find the `Daemons` card 3. Click `View` in the `Daemons` card to see a list of existing `Daemons` 4. In the list of Daemons, find the daemon you want to edit and click the `NAME` of the daemon 5. On the Daemon details page, click `EDIT` in the upper-right corner 6. Follow the prompts then click `CONFIRM` 7. In the `Daemon` details view, the recently updated `Daemon` details can be seen # Daemons Many applications rely on background processes, or daemons, to keep critical programs alive and running continuously. Devopness simplifies the management of these daemons by providing a centralized platform, allowing you to configure, monitor, and maintain these persistent processes with ease. Daemons run as background processes and can automatically restart a program if it fails or when its code/command line is modified. # Remove a Daemon Remove a Daemon when it is no longer needed. 1. On Devopness, navigate to a project, then select an environment 2. Find the `Daemons` card 3. Click `View` in the `Daemons` card to see a list of existing `Daemons` 4. In the list of Daemons, find the daemon you want to remove and click the `NAME` of the daemon 5. On the upper-right corner of the daemon details view, click `REMOVE` 6. Follow the prompts then click `REMOVE DAEMON` 7. In the list of Daemons, the recently removed `Daemon` will be gone # Add an Environment Create an environment to separate infrastructure and release flow inside one project. ## Goal [#goal] Add a separate infrastructure setup for development, staging, production, or a custom release flow. ## Prerequisites [#prerequisites] * Permission to add environments in the target project * The correct project selected in the organization ## What you need [#what-you-need] ### Name [#name] A clear environment name, such as `Production`, `Staging`, or `Development`. ### Environment type [#environment-type] The type that matches how you plan to use this environment. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Add a Production environment to the `acme-platform` project" * "Create a Staging environment in my current project" * "Add a Development environment named `dev`" ## After you save [#after-you-save] * The environment appears in the environments list * You can add servers, applications, and other resources in it ## Verify [#verify] * The environment appears with the name and type you set * You can open it and start adding resources ## Common issues [#common-issues] * You do not see `Add Environment`: check your project permissions * Environment name is already used in this project: choose a different name * You cannot save: confirm you have permission to add environments ## What to do next [#what-to-do-next] * [List environments](/docs/environments/list-environments) * [Add applications](/docs/applications/add-application) in the new environment # Archive an Environment Archive an environment to make it read-only while keeping its setup and history. ## Goal [#goal] Pause an old release flow without deleting its configuration. ## Prerequisites [#prerequisites] * Permission to archive environments * The target environment to archive ## What you need [#what-you-need] * The environment you want to archive * Confirmation that active changes should stop in this environment ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Archive the `legacy-staging` environment in `acme-platform`" * "Archive the old hotfix environment in my project" ## After you save [#after-you-save] * The environment becomes read-only * Settings, history, and team memberships stay in place ## Verify [#verify] * The environment appears in the archived list * You cannot make active changes in it ## Common issues [#common-issues] * You cannot archive: check for resources that still need manual cleanup * You do not have permission to archive this environment Archiving does not remove cloud resources. Remove unused resources before archive to avoid extra cost. Archived environments are read-only. Only project owners can restore them. ## What to do next [#what-to-do-next] * [Find an archived environment](/docs/environments/find-archived-environment) * [Unarchive an environment](/docs/environments/unarchive-environment) when you need it active again # Find an Archived Environment Find environments that are archived and no longer active. ## Goal [#goal] Locate archived environments and review their resources when needed. ## What you need [#what-you-need] * The correct project selected * Permission to view archived environments ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "List archived environments in `acme-platform`" * "Show archived environments in my current project" ## What you see [#what-you-see] * Archived environments listed separately from active ones * Enough detail to open one before restoring or removing it ## Verify [#verify] * The archived list shows the environment you expected * You can open it and review its state ## Common issues [#common-issues] * The archived list is empty: confirm the environment is archived first * You cannot view details: confirm your role and permission set ## What to do next [#what-to-do-next] * [Unarchive an environment](/docs/environments/unarchive-environment) * [Remove an environment](/docs/environments/remove-environment) when you no longer need it # Environments An **environment** is a separate infrastructure setup inside one project. Each environment has its own servers, applications, credentials, files, pipelines, and access rules. Nothing in one environment is shared automatically with another. Names like `Development`, `Staging`, and `Production` are common, but an environment is not just a label: dev might run on one or two servers while production runs on twenty servers behind a load balancer, or on serverless infrastructure in the cloud. You can also name an environment after a client when you manage separate infrastructure per client, for example `customer-acme` or `customer-abc`. ## About [#about] * Use environments when you need fully independent infrastructure inside one project * Resources in one environment (servers, applications, SSH keys, daemons, cron jobs, virtual hosts, credentials) do not exist in another unless you create them there * Most teams deploy to dev first, then move stable work to staging and production * Each environment can scale differently: smaller setups for testing, larger setups for live traffic ## Who this is for [#who-this-is-for] * Teams that need separate dev, staging, and production infrastructure * Operators who need different servers, credentials, or access per release flow * Founders who want one project with isolated dev and production setups ## Think of it like this [#think-of-it-like-this] * **Project:** one product or client * **Environment:** a separate copy of infrastructure for that product (its own servers and applications) * **Application:** one git repository connected to that environment ## Start here [#start-here] * Confirm you are in the right project * Create a first `Production` environment * Add `Development` and `Staging` when you need separate infrastructure and release flow * [Add applications](/docs/applications/add-application) in each environment * Add client or hotfix environments only when needed * Example: a security hotfix environment with separate servers and credentials * Example: a staging environment for demoing work in progress ## When to split environments [#when-to-split-environments] Start with one `Production` environment while validating the first release. Add another environment when you need stronger isolation: * You want a safe place to test before production (dev or staging) * Different credentials, domains, or deployment permissions per setup * Different servers, applications, or supporting resources (one dev server vs many production servers) * Temporary client-specific or hotfix work that must not affect production * Different infrastructure per team, region, or compliance requirement ## Common setups [#common-setups] ### Product company or startup [#product-company-or-startup] * Start with one `Production` environment if you are validating a first version * Add `Development`, `Staging`, or custom environments when you need separate infrastructure * Deploy to dev first, validate, then move stable work to staging and production ### Agency or client-specific software [#agency-or-client-specific-software] * Start with your organization and one project per client * One project per client can include `Production`, `Staging`, and custom environments * Keep each client's workflow separate from the others * Use custom environments for one-off client changes without touching other releases ## Why this matters [#why-this-matters] * It reduces accidental changes across dev, staging, and production * It makes it easier to decide what to test and deploy next * It lets teams set safer access per environment * It keeps infrastructure, applications, and credentials isolated when you need a clean separation ## What to do next [#what-to-do-next] * Add your first [environment](/docs/environments/add-environment) * Review [Projects](/docs/projects/) if you still need to create the parent project * [Add applications](/docs/applications/add-application) inside the environment # List Environments List environments in one project. ## Goal [#goal] See which environments exist before you add resources or make changes. ## What you need [#what-you-need] * The correct project selected * Permission to read environments ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "List the environments in the `acme-platform` project" * "Show environments in my current project" * "List Production and Staging environments for `northwind`" ## What you see [#what-you-see] * Environment names and types * A way to open one environment for details ## Verify [#verify] * The list shows the project you expected * The environment names match what you need to work with ## Common issues [#common-issues] * Empty list: confirm your role allows environment visibility * Wrong project selected: switch to the intended project ## What to do next [#what-to-do-next] * [View an environment](/docs/environments/view-environment) * [Add an environment](/docs/environments/add-environment) # Remove an Environment Delete an environment when you no longer need that separate infrastructure setup. ## Goal [#goal] Remove an unused environment after your release flow changes. Removing this environment is permanent. Confirm this environment is no longer needed before you continue. Removed environments no longer keep an active deployment target. ## Prerequisites [#prerequisites] * Permission to edit and remove environments * A target environment that is safe to delete * No active resources still depend on it ## What you need [#what-you-need] * The environment you want to remove * Confirmation that deletion is intentional ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Remove the `hotfix-2024` environment from `acme-platform`" * "Delete the unused Staging environment in my project" Check the environment name before you confirm deletion. ## Verify [#verify] * The environment no longer appears in the environment list * Remaining environments still work as expected ## Common issues [#common-issues] * Remove is disabled: check if there are active resources still linked to the environment * You do not have permission to remove this environment: ask a project owner for access * You need one environment for current workload: remove only after creating a replacement ## What to do next [#what-to-do-next] * [List environments](/docs/environments/list-environments) * [Archive an environment](/docs/environments/archive-environment) when you want to keep history instead of deleting # Unarchive an Environment Restore an archived environment so you can deploy and change it again. ## Goal [#goal] Bring a paused environment back to active use. ## Prerequisites [#prerequisites] * Permission to unarchive environments * An environment currently in archived state ## What you need [#what-you-need] * The archived environment you want to restore ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Unarchive the `legacy-staging` environment in `acme-platform`" * "Restore the archived hotfix environment in my project" ## After you save [#after-you-save] * The environment becomes active again * Team members can access it based on current roles ## Verify [#verify] * The environment appears in the active environment list * You can deploy and edit resources again ## Common issues [#common-issues] * Unarchive is disabled: confirm the environment is truly archived * You do not have permission to unarchive this environment ## What to do next [#what-to-do-next] * [View the environment](/docs/environments/view-environment) * [List environments](/docs/environments/list-environments) # View Environment Open one environment to inspect its resources, settings, and access. ## Goal [#goal] Check what is configured before you deploy, edit settings, or add resources. ## What you need [#what-you-need] * The correct project selected * Permission to read the environment * The environment name or list entry you want to open ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Show me the Production environment in `acme-platform`" * "Open the Staging environment details" * "List resources in my current environment" ## What you see [#what-you-see] * A summary of resources in the environment * Team memberships and settings * Actions such as archive, unarchive, or remove ## Verify [#verify] * The details page shows the environment you expected * Resources and settings match the current setup ## Common issues [#common-issues] * Missing resources on the page: add resources first * You cannot edit settings: your role may be read-only for this environment ## What to do next [#what-to-do-next] * [Add an environment](/docs/environments/add-environment) when you need another setup * [Add applications](/docs/applications/add-application) in this environment * [Archive an environment](/docs/environments/archive-environment) when you want to pause it # Add a File Add a configuration file to an application so Devopness uses its settings during deploy, without hard-coding them into your code. Common examples are a `.env` file with environment variables, or app-specific config that should not live in the repository. ## Goal [#goal] Store configuration settings and environment variables for an application before you deploy it. ## Prerequisites [#prerequisites] * You can update applications in this environment (`application:update`) * The application already exists in the selected environment ## What you need [#what-you-need] ### Application [#application] The application that should load this configuration file during deploy. ### File name [#file-name] The name of the file, for example `.env`. Make sure the file is where your application and its packages expect to read it. ### File content [#file-content] The settings and environment variables the application needs at runtime, one per line, for example: ```text DATABASE_URL=postgres://user:pass@host:5432/acme API_KEY=your-api-key ``` Use the same key names your application reads so it picks up the values on the next deploy. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme-inc`, project `acme-platform`, add a `.env` file to the `acme-api` application in the Production environment with `DATABASE_URL` and `API_KEY`." * "In organization `acme-inc`, project `acme-platform`, create a configuration file `config.yaml` for `acme-web` in Staging and set environment variables from this list." ## After you save [#after-you-save] * A new deployment is required for your changes to take effect. [Deploy the application](/docs/applications/deploy-application) so the settings are applied ## Verify [#verify] * The file appears in the application's configuration file list with the expected name, path, and content * A new deploy of the application picks up the values you set ## Common issues [#common-issues] ### Settings have no effect after deploy [#settings-have-no-effect-after-deploy] * Confirm the file name and path match what your application reads * Confirm the key names match the ones your application expects * [Deploy](/docs/applications/deploy-application) again after saving the file, because changes take effect on deploy ### You do not see Add File [#you-do-not-see-add-file] * Confirm you have `application:update` for this environment ## What to do next [#what-to-do-next] * [Deploy Application](/docs/applications/deploy-application) to apply the configuration * [View a File](/docs/files/view-file) to review the file you added # Edit a File Update a configuration file so your application uses the latest settings and environment variables on its next deploy. Edit a file when values change, such as a new database URL or API key, without hard-coding them into your code. ## Goal [#goal] Change the name or content of a configuration file attached to an application. ## Prerequisites [#prerequisites] * You can update applications in this environment (`application:update`) * The configuration file already exists for the application ## What you need [#what-you-need] ### Application [#application] The application whose configuration file you want to update. ### File name and content [#file-name-and-content] The new name or content for the file, for example a revised `.env`. Keep the same key names your application reads so it picks up the updated values on the next deploy. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme-inc`, project `acme-platform`, update the `DATABASE_URL` in the `.env` file of `acme-api` in the Production environment." * "In organization `acme-inc`, project `acme-platform`, rename the `config.yaml` file of `acme-web` in Staging and keep its current content." ## After you save [#after-you-save] * A new deployment is required for your changes to take effect. [Deploy the application](/docs/applications/deploy-application) so the updated settings are applied ## Verify [#verify] * The file shows the new name and content in the application's configuration file list * A new deploy of the application picks up the updated values ## Common issues [#common-issues] ### New values have no effect after deploy [#new-values-have-no-effect-after-deploy] * Confirm the key names still match what your application reads * Confirm you saved before deploying again * [Deploy](/docs/applications/deploy-application) again after saving, because changes take effect on deploy ### You do not see Edit [#you-do-not-see-edit] * Confirm you have `application:update` for this environment ## What to do next [#what-to-do-next] * [View a File](/docs/files/view-file) to confirm the updated settings * [Deploy Application](/docs/applications/deploy-application) to apply the configuration # Files Configuration files are used to store configuration settings and environment variables that are used by application and infrastructure resources. Example: a `.env` file (also known as "dotenv") containing environment variables for an `Application`. Using Devopness you can easily manage and organize multiple configuration files on your environment resources defining custom variables to be set during a deploy, without the need of hard-coding them directly into your application code and without the need of SSH into your server every time an environment variable needs to be updated. # Remove a File Remove a configuration file from an application when it is no longer needed, such as a `.env` whose settings are obsolete. ## Goal [#goal] Delete a configuration file so the application no longer loads its settings on the next deploy. ## Prerequisites [#prerequisites] * You can update applications in this environment (`application:update`) * The configuration file you want to remove exists ## What you need [#what-you-need] ### Application [#application] The application whose configuration file you want to remove. ### File [#file] The configuration file to delete. Confirm the file is no longer needed before you remove it, because the removal is permanent. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme-inc`, project `acme-platform`, remove the `.env` file from the `acme-api` application in the Production environment." * "In organization `acme-inc`, project `acme-platform`, delete the obsolete `config.yaml` file of `acme-web` in Staging." ## After you remove [#after-you-remove] * A new deployment is required for your changes to take effect. [Deploy the application](/docs/applications/deploy-application) so the application stops loading the removed settings ## Verify [#verify] * The file no longer appears in the application's configuration file list * A new deploy of the application no longer loads that file's settings ## Common issues [#common-issues] ### The application still uses the removed settings [#the-application-still-uses-the-removed-settings] * Confirm the file is gone from the configuration file list * [Deploy](/docs/applications/deploy-application) again, because removal takes effect on deploy * Check whether the value is set elsewhere, such as in the repository or another file ### You do not see Remove [#you-do-not-see-remove] * Confirm you have `application:update` for this environment ## What to do next [#what-to-do-next] * [Add a File](/docs/files/add-file) if you need to replace the removed configuration * [Deploy Application](/docs/applications/deploy-application) to apply the change # View a File View the details of a configuration file attached to an application, including its name, path, content, and metadata. Use this page to confirm what an application loads at runtime, for example credentials and environment variables. ## Goal [#goal] Review an application's configuration file and the settings it provides. ## What you see [#what-you-see] * The file's **name** and **path** within the application or repository * The file's **content**, such as the environment variables in a `.env` * When the file was **created** and **last updated** ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme-inc`, project `acme-platform`, show the `.env` file content of `acme-api` in the Production environment." * "In organization `acme-inc`, project `acme-platform`, list the configuration files of `acme-web` in Staging and show the one named `config.yaml`." ## Verify [#verify] * You can read the expected file name, path, and content * The settings shown match what the application should load ## Common issues [#common-issues] ### The file content looks incomplete [#the-file-content-looks-incomplete] * Confirm you are viewing the right file and application * [Edit the File](/docs/files/edit-file) if a value is missing or wrong, then deploy again ## What to do next [#what-to-do-next] * [Edit a File](/docs/files/edit-file) to change the settings * [Remove a File](/docs/files/remove-file) when the file is no longer needed # Legal This section contains all legal agreements for our services, including terms of service and privacy policy. By using our services, you agree to these terms. # Privacy Policy Last updated January 26, 2023 ## 1. Introduction [#1-introduction] Welcome to **Devopness Tecnologia LTDA**. **Devopness Tecnologia LTDA** (“us”, “we”, or “our” or just "Devopness") operates [www.devopness.com](http://www.devopness.com) (hereinafter referred to as **“Service”**). Our Privacy Policy governs your visit to [www.devopness.com](http://www.devopness.com), and explains how we collect, safeguard and disclose information that results from your use of our Service. We use your data to provide and improve Service. By using Service, you agree to the collection and use of information in accordance with this policy. Unless otherwise defined in this Privacy Policy, the terms used in this Privacy Policy have the same meanings as in our Terms and Conditions. Our Terms and Conditions (“Terms”) govern all use of our Service and together with the Privacy Policy constitutes your agreement with us (“agreement”). ## 2. Definitions [#2-definitions] **SERVICE** - means the [www.devopness.com](http://www.devopness.com) website operated by Devopness **PERSONAL DATA** - means data about a living individual who can be identified from those data (or from those and other information either in our possession or likely to come into our possession). **USAGE DATA** - is data collected automatically either generated by the use of Service or from Service infrastructure itself (for example, the duration of a page visit). **COOKIES** - are small files stored on your device (computer or mobile device). **DATA CONTROLLER** - means a natural or legal person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed. For the purpose of this Privacy Policy, we are a Data Controller of your data. **DATA PROCESSORS (OR SERVICE PROVIDERS)** - means any natural or legal person who processes the data on behalf of the Data Controller. We may use the services of various Service Providers in order to process your data more effectively. **DATA SUBJECT** - is any living individual who is the subject of Personal Data. **THE USER** - is the individual using our Service. The User corresponds to the Data Subject, who is the subject of Personal Data. ## 3. Information Collection and Use [#3-information-collection-and-use] We collect several different types of information for various purposes to provide and improve our Service to you. ## 4. Types of Data Collected [#4-types-of-data-collected] **Personal Data** ‍While using our Service, we may ask you to provide us with certain personally identifiable information that can be used to contact or identify you (“**Personal Data**”). Personally identifiable information may include, but is not limited to: 1. Email address 2. First name and last name 3. Phone number 4. Address, State, Province, ZIP/Postal code, City 5. Cookies and Usage Data ‍ We may use your Personal Data to contact you with newsletters, marketing or promotional materials and other information that may be of interest to you. You may opt out of receiving any, or all, of these promotional emails from us by following the unsubscribe link. **Usage Data** ‍We may also collect information that your browser sends whenever you visit our Service or when you access Service by or through a mobile device (“**Usage Data**”). This Usage Data may include information such as your computer's Internet Protocol address (e.g. IP address), browser type, browser version, the pages of our Service that you visit, the time and date of your visit, the time spent on those pages, unique device identifiers and other diagnostic data. When you access Service with a mobile device, this Usage Data may include information such as the type of mobile device you use, your mobile device unique ID, the IP address of your mobile device, your mobile operating system, the type of mobile Internet browser you use, unique device identifiers and other diagnostic data. **Tracking Cookies Data** We use cookies and similar tracking technologies to track the activity on our Service and we hold certain information. Cookies are files with a small amount of data which may include an anonymous unique identifier. Cookies are sent to your browser from a website and stored on your device. Other tracking technologies are also used such as beacons, tags and scripts to collect and track information and to improve and analyze our Service. You can instruct your browser to refuse all cookies or to indicate when a cookie is being sent. However, if you do not accept cookies, you may not be able to use some portions of our Service. Examples of Cookies we use: 1. **Session Cookies**: We use Session Cookies to operate our Service. 2. **Preference Cookies**: We use Preference Cookies to remember your preferences and various settings. 3. **Security Cookies**: We use Security Cookies for security purposes. 4. **Advertising Cookies**: Advertising Cookies are used to serve you with advertisements that may be relevant to you and your interests. **Other Data** ‍While using our Service, we may also collect the following information: sex, age, date of birth, place of birth, actual address, telephone number (work, mobile),office location and other data. ## 5. Use of Data [#5-use-of-data] Devopness uses the collected data for various purposes: 1. to provide and maintain our Service; 2. to notify you about changes to our Service; 3. to allow you to participate in interactive features of our Service when you choose to do so; 4. to provide customer support; 5. to gather analysis or valuable information so that we can improve our Service; 6. to monitor the usage of our Service; 7. to detect, prevent and address technical issues; 8. to fulfill any other purpose for which you provide it; 9. to carry out our obligations and enforce our rights arising from any contracts entered into between you and us, including for billing and collection; 10. to provide you with notices about your account and/or subscription, including expiration and renewal notices, email-instructions, etc.; 11. to provide you with news, special offers and general information about other goods, services and events which we offer that are similar to those that you have already purchased or enquired about unless you have opted not to receive such information; 12. in any other way we may describe when you provide the information; 13. for any other purpose with your consent. ## 6. Retention of Data [#6-retention-of-data] We will retain your Personal Data only for as long as is necessary for the purposes set out in this Privacy Policy. We will retain and use your Personal Data to the extent necessary to comply with our legal obligations (for example, if we are required to retain your data to comply with applicable laws), resolve disputes, and enforce our legal agreements and policies. We will also retain Usage Data for internal analysis purposes. Usage Data is generally retained for a shorter period, except when this data is used to strengthen the security or to improve the functionality of our Service, or we are legally obligated to retain this data for longer time periods. ## 7. Transfer of Data [#7-transfer-of-data] Your information, including Personal Data, may be transferred to – and maintained on – computers located outside of your state, province, country or other governmental jurisdiction where the data protection laws may differ from those of your jurisdiction. Your consent to this Privacy Policy followed by your submission of such information represents your agreement to that transfer. Devopness will take all the steps reasonably necessary to ensure that your data is treated securely and in accordance with this Privacy Policy and no transfer of your Personal Data will take place to an organization or a country unless there are adequate controls in place including the security of your data and other personal information. ## 8. Disclosure of Data [#8-disclosure-of-data] We may disclose personal information that we collect, or you provide: 1. **Disclosure for Law Enforcement** - Under certain circumstances, we may be required to disclose your Personal Data if required to do so by law or in response to valid requests by public authorities. 2. **Business Transaction** - If we or our subsidiaries are involved in a merger, acquisition or asset sale, your Personal Data may be transferred. 3. **Other cases. We may disclose your information also:** 1. to our subsidiaries and affiliates; 2. to contractors, service providers, and other third parties we use to support our business; 3. to fulfill the purpose for which you provide it; 4. for the purpose of including your company’s logo on our website; 5. for any other purpose disclosed by us when you provide the information; 6. if we believe disclosure is necessary or appropriate to protect the rights, property, or safety of the Company, our customers, or others. 7. with your consent in any other cases; ## 9. Security of Data [#9-security-of-data] The security of your data is important to us but remember that no method of transmission over the Internet or method of electronic storage is 100% secure. While we strive to use commercially acceptable means to protect your Personal Data, we cannot guarantee its absolute security. ## 10. Your Data Protection Rights Under General Data Protection Regulation (GDPR)‍ [#10-your-data-protection-rights-under-general-data-protection-regulation-gdpr] If you are a resident of the European Union (EU) and European Economic Area (EEA), you have certain data protection rights, covered by GDPR. – See more at ‍ [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj) We aim to take reasonable steps to allow you to correct, amend, delete, or limit the use of your Personal Data. If you wish to be informed what Personal Data we hold about you and if you want it to be removed from our systems, please email us at [legal@devopness.com](mailto\:legal@devopness.com) . In certain circumstances, you have the following data protection rights: 1. the right to access, update or to delete the information we have on you; 2. the right of rectification. You have the right to have your information rectified if that information is inaccurate or incomplete; 3. the right to object. You have the right to object to our processing of your Personal Data; 4. the right of restriction. You have the right to request that we restrict the processing of your personal information; 5. the right to data portability. You have the right to be provided with a copy of your Personal Data in a structured, machine-readable and commonly used format; 6. the right to withdraw consent. You also have the right to withdraw your consent at any time where we rely on your consent to process your personal information; Please note that we may ask you to verify your identity before responding to such requests. Please note, we may not be able to provide Service without some necessary data. You have the right to complain to a Data Protection Authority about our collection and use of your Personal Data. For more information, please contact your local data protection authority in the European Economic Area (EEA). ## 11. Your Data Protection Rights under the California Privacy Protection Act (CalOPPA) [#11-your-data-protection-rights-under-the-california-privacy-protection-act-caloppa] CalOPPA is the first state law in the nation to require commercial websites and online services to post a privacy policy. The law’s reach stretches well beyond California to require a person or company in the United States (and conceivable the world) that operates websites collecting personally identifiable information from California consumers to post a conspicuous privacy policy on its website stating exactly the information being collected and those individuals with whom it is being shared, and to comply with this policy. – See more at: [https://consumercal.org/about-cfc/cfc-education-foundation/california-online-privacy-protection-act-caloppa-3/](https://consumercal.org/about-cfc/cfc-education-foundation/california-online-privacy-protection-act-caloppa-3/) According to CalOPPA we agree to the following: 1. users can visit our site anonymously; 2. our Privacy Policy link includes the word “Privacy”, and can easily be found on the page specified above on the home page of our website; 3. users will be notified of any privacy policy changes on our Privacy Policy Page; 4. users are able to change their personal information by emailing us at [legal@devopness.com](mailto\:legal@devopness.com) Our Policy on “Do Not Track” Signals: We honor Do Not Track signals and do not track, plant cookies, or use advertising when a Do Not Track browser mechanism is in place. Do Not Track is a preference you can set in your web browser to inform websites that you do not want to be tracked. You can enable or disable Do Not Track by visiting the Preferences or Settings page of your web browser. ## 12. Your Data Protection Rights under the California Consumer Privacy Act (CCPA) [#12-your-data-protection-rights-under-the-california-consumer-privacy-act-ccpa] If you are a California resident, you are entitled to learn what data we collect about you, ask to delete your data and not to sell (share) it. To exercise your data protection rights, you can make certain requests and ask us: 1. **What personal information we have about you.** If you make this request, we will return to you: 1. The categories of personal information we have collected about you. 2. The categories of sources from which we collect your personal information. 3. The business or commercial purpose for collecting or selling your personal information. 4. The categories of third parties with whom we share personal information. 5. The specific pieces of personal information we have collected about you. 6. A list of categories of personal information that we have sold, along with the category of any other company we sold it to. If we have not sold your personal information, we will inform you of that fact. 7. A list of categories of personal information that we have disclosed for a business purpose, along with the category of any other company we shared it with. 2. **To delete your personal information.** If you make this request, we will delete the personal information we hold about you as of the date of your request from our records and direct any service providers to do the same. In some cases, deletion may be accomplished through de-identification of the information. If you choose to delete your personal information, you may not be able to use certain functions that require your personal information to operate. 3. **To stop selling your personal information.** We do not sell your personal information for monetary consideration. However, under some circumstances, a transfer of personal information to a third party, or within our family of companies, without monetary consideration may be considered a “sale” under California law. Please note, you are entitled to ask us to provide you with this information up to two times in a rolling twelve-month period. When you make this request, the information provided may be limited to the personal information we collected about you in the previous 12 months. If you submit a request to stop selling your personal information, we will stop making such transfers. If you are a California resident, to opt-out of the sale of your personal information, click “Do Not Sell My Personal Information” at the bottom of our home page to submit your request. Please note, if you ask us to delete or stop selling your data, it may impact your experience with us, and you may not be able to participate in certain programs or membership services which require the usage of your personal information to function. But in no circumstances, we will discriminate against you for exercising your rights. To exercise your California data protection rights described above, please send your request(s) to [legal@devopness.com](mailto\:legal@devopness.com) . ‍ Your data protection rights, described above, are covered by the CCPA, short for the California Consumer Privacy Act. To find out more, visit the official California Legislative Information website. The CCPA took effect on 01/01/2020. ## 13. Service Providers [#13-service-providers] We may employ third party companies and individuals to facilitate our Service (“**Service Providers**”), provide Service on our behalf, perform Service-related services or assist us in analysing how our Service is used. These third parties have access to your Personal Data only to perform these tasks on our behalf and are obligated not to disclose or use it for any other purpose. ## 14. Analytics [#14-analytics] We may use third-party Service Providers to monitor and analyze the use of our Service. **Google Analytics** ‍Google Analytics is a web analytics service offered by Google that tracks and reports website traffic. Google uses the data collected to track and monitor the use of our Service. This data is shared with other Google services. Google may use the collected data to contextualise and personalise the ads of its own advertising network. For more information on the privacy practices of Google, please visit the Google Privacy Terms web page: [https://policies.google.com/privacy?hl=en](https://policies.google.com/privacy?hl=en) We also encourage you to review Google's policy for safeguarding your data: [https://support.google.com/analytics/answer/6004245](https://support.google.com/analytics/answer/6004245) **Segment.io** ‍Segment.io is a web traffic analysis tool. You can read the Privacy Policy for Segment.io here: [https://segment.com/legal/privacy/](https://segment.com/legal/privacy/) **Mixpanel** ‍Mixpanel is provided by Mixpanel Inc. You can prevent Mixpanel from using your information for analytics purposes by opting-out. To opt-out of Mixpanel service, please visit this page: [https://mixpanel.com/optout](https://mixpanel.com/optout) For more information on what type of information Mixpanel collects, please visit the Terms of Use page of Mixpanel: [https://mixpanel.com/terms/](https://mixpanel.com/terms/) ## 15. Behavioral Remarketing [#15-behavioral-remarketing] Devopness uses remarketing services to advertise on third party websites to you after you visited our Service. We and our third-party vendors use cookies to inform, optimise and serve ads based on your past visits to our Service. **Google Ads (AdWords)** ‍Google Ads (AdWords) remarketing service is provided by Google Inc. You can opt-out of Google Analytics for Display Advertising and customize the Google Display Network ads by visiting the Google Ads Settings page: [http://www.google.com/settings/ads](http://www.google.com/settings/ads) Google also recommends installing the Google Analytics Opt-out Browser Add-on – [https://tools.google.com/dlpage/gaoptout](https://tools.google.com/dlpage/gaoptout) – for your web browser. Google Analytics Opt-out Browser Add-on provides visitors with the ability to prevent their data from being collected and used by Google Analytics. For more information on the privacy practices of Google, please visit the Google Privacy Terms web page: [https://policies.google.com/privacy?hl=en](https://policies.google.com/privacy?hl=en) **Bing Ads Remarketing** ‍Bing Ads remarketing service is provided by Microsoft Inc. You can opt-out of Bing Ads interest-based ads by following their instructions: [https://advertise.bingads.microsoft.com/en-us/resources/policies/personalized-ads](https://advertise.bingads.microsoft.com/en-us/resources/policies/personalized-ads) You can learn more about the privacy practices and policies of Microsoft by visiting their Privacy Policy page: [https://privacy.microsoft.com/en-us/PrivacyStatement](https://privacy.microsoft.com/en-us/PrivacyStatement) **Twitter** ‍Twitter remarketing service is provided by Twitter Inc. You can opt-out from Twitter's interest-based ads by following their instructions: [https://support.twitter.com/articles/20170405](https://support.twitter.com/articles/20170405) You can learn more about the privacy practices and policies of Twitter by visiting their Privacy Policy page: [https://twitter.com/privacy](https://twitter.com/privacy) ## 16. Payments [#16-payments] We may provide paid products and/or services within Service. In that case, we use third-party services for payment processing (e.g. payment processors). We will not store or collect your payment card details. That information is provided directly to our third-party payment processors whose use of your personal information is governed by their Privacy Policy. These payment processors adhere to the standards set by PCI-DSS as managed by the PCI Security Standards Council, which is a joint effort of brands like Visa, Mastercard, American Express and Discover. PCI-DSS requirements help ensure the secure handling of payment information. The payment processors we work with are: **Paddle:** All purchases made through the Website are processed by a third party payment processor, Paddle ([https://www.paddle.com](https://www.paddle.com)). Paddle may ask you for personal and/or non-personal information, such as your name, address, email address, credit card information, or other Personal Information. Paddle has a privacy policy ([https://www.paddle.com/legal-buyers/](https://www.paddle.com/legal-buyers/)) that describes their collection and use of personal information. Tailwind does not control Paddle or its collection or use of information. Any questions or concerns about Paddle’s practices should be directed to Paddle. Paddle provides us with certain non-personal information relating to purchases made by visitors to the Website. The non-personal information may include details of the purchase such as the date, amount paid, and product purchased. The non-personal purchase information may be linked to the Personal Information you provide to us (typically limited to your email address, as stated above). Paddle does not supply us with any of your other Personal Information such as your name, street address, or credit card information. ## 17. Links to Other Sites [#17-links-to-other-sites] Our Service may contain links to other sites that are not operated by us. If you click a third party link, you will be directed to that third party's site. We strongly advise you to review the Privacy Policy of every site you visit. We have no control over and assume no responsibility for the content, privacy policies or practices of any third party sites or services. ## 18. Children's Privacy [#18-childrens-privacy] Our Services are not intended for use by children under the age of 13 (“**Children**”). We do not knowingly collect personally identifiable information from Children under 13. If you become aware that a Child has provided us with Personal Data, please contact us. If we become aware that we have collected Personal Data from Children without verification of parental consent, we take steps to remove that information from our servers. ## 19. Changes to This Privacy Policy [#19-changes-to-this-privacy-policy] We may update our Privacy Policy from time to time. We will notify you of any changes by posting the new Privacy Policy on this page. We will let you know via email and/or a prominent notice on our Service, prior to the change becoming effective and update “effective date” at the top of this Privacy Policy. You are advised to review this Privacy Policy periodically for any changes. Changes to this Privacy Policy are effective when they are posted on this page. ## 20. Contact Us [#20-contact-us] ‍If you have any questions about this Privacy Policy, please contact us: By email: [legal@devopness.com](mailto\:legal@devopness.com) # Terms of Service ## PLEASE READ THESE TERMS AND CONDITIONS (“Terms”) CAREFULLY BEFORE USING THIS PLATFORM [#please-read-these-terms-and-conditions-terms-carefully-before-using-this-platform] We are **Devopness Tecnologia LTDA** trading as **Devopness**. By using our Platform you accept these Terms. If you do not agree to these Terms, you must not use our Platform. In using our Platform we may process your personal data, more information about this can be found here. Where you are not a consumer, you confirm that you have authority to bind the business on behalf of which you are accepting these Terms. In that context, references to “you” or “your” will be to that business. Otherwise it will refer to you, the individual entering into these Terms. ## ACCOUNT CREATION AND SECURITY [#account-creation-and-security] * **You must create an account to use our Platform.** When you register for an account on our Platform you must ensure that all information you provide to us is accurate and kept up to date. Upon registration we grant to you the personal, non-transferable right and license to use the Platform for your own internal business purposes, until terminated as set out in these Terms. * **You must keep your account details safe.** Any piece of information as part of our security procedures including your username and password must be treated as confidential. We have the right to disable any user identification code or password at any time. If you know or suspect that anyone other than you knows your user identification code or password, you must promptly notify us at [legal@devopness.com](mailto\:legal@devopness.com). * **These terms are binding.** By using our Platform and downloading any of our Website Content you acknowledge that these terms will apply and you have legal capacity to enter into contracts in the country you live. You also confirm that when acting on behalf of a business you have authority to bind them to these terms. If this is not the case, you should not use our Platform. * **Subscription fees.** A free subscription option is available, but if you wish to set up a paid subscription, you will only be able to use the premium services if you pay the relevant fees. You will be liable to pay for all taxes and duties imposed by the relevant authorities, all prices listed on our Platform are exclusive of these. * **Payment terms.** Where you sign up to a monthly plan with us, all subscription fees will be payable in advance at the beginning of each subscription period. You will be able to cancel your monthly subscription at any time which will give you access to premium services in our Platform until the end of the current paid term, after which no further payments will be taken. * **Cancellation, Refunds, And Guarantees.** If you purchase a subscription to one or more of our services, you can cancel your subscription at any time by logging into your account in our Platform. Your cancellation will take effect at the end of the current paid term. No refunds will be provided for our subscription services. * **Third party subscriptions.** Some features on our platform may require you to have a paid subscription with external providers. These fees are independent of any charges paid to us, and it is your responsibility to establish these accounts and abide by the terms of the third-party provider, this includes but is not limited to, server providers such as Amazon Web Services, DigitalOcean, Google Cloud Platform, Microsoft Azure and source control providers like GitHub, GitLab, and Bitbucket. * **Upgrades and downgrades.** Where you upgrade or downgrade the services you can access on our Platform and you are on a monthly plan, we will amend your fees payable on the next billing cycle. By downgrading your services it may cause you to lose features and/ or data. We will in no way be liable for this. In the event you exceed the limit of your current plan, we may decide to upgrade your account accordingly to facilitate your usage. We will provide you with 14 days notice prior to upgrading your account in which you can choose to object to this change of Platform access. * **Merchant of record.** Where you pay fees for the services we provide to you as part of your access to our Platform, we will use a merchant of record: Paddle, to recover these fees and any applicable taxes. Any invoices or payments from your account will be under the name “Paddle”. ## OUR PLATFORM [#our-platform] * **What is our platform?** Our **“Platform”** to our platform and all other related services and documentation that gives you access to products and services (**“Website Content”**), except for User Content. * **User Content.** Our Platform allows you to create and manage multiple cloud infrastructure projects, environments, which allow managing infrastructure resources such as applications, servers, cron jobs, SSH keys, daemons, network rules, and services. * **Action.** Any operation executed by Devopness on user environment resources is considered an action, and it will only be performed if the user has sufficient action credits available. * **Action credits.** Each plan on Devopness will have a set number of action credits that will become available on a monthly basis upon processing of the subscription fees. * **Performance of the Platform.** During your use of the Platform, we will take steps to ensure that the Platform functions as described at the point you signed up. Although we will introduce technology to prevent malware and viruses we do not guarantee that our Platform will be secure or free from bugs or viruses. You are responsible for configuring your information technology, computer programmes and platform to access our Platform. * **What happens when the Platform stops working as described.** In the event you report to us a substantial error with the Platform, we will seek to correct this within a reasonable amount of time – where legally permitted, this will be your sole remedy. * **We may suspend or withdraw our Platform.** We do not guarantee that our Platform, or any of the Website Content or the User Content, will always be available or be uninterrupted. We may suspend or withdraw or restrict the availability of all or any part of our Platform for business and operational reasons. You are also responsible for ensuring that all persons who access our Platform through your internet connection are aware of and comply with these Terms. * **What action we may take in the event of a breach.** When we consider that a breach of these Terms has occurred, we may take such action as we deem appropriate including: * immediate, temporary or permanent withdrawal of your right to use our Platform; * immediate, temporary or permanent removal of any User Content uploaded by you to our Platform; * legal action against you; and/or * disclosure of such information to law enforcement authorities as we reasonably feel is necessary or as required by law. * **You must maintain a secure internet connection.** Where you lose access to the Platform and any User Content due to a disruption in your telecommunications or internet services, we will in no way be liable for any losses suffered. * **Where our Platform contains links to other sites, User Content and resources provided by third parties.** These are provided for your information only. They should not be interpreted as approval by us of those linked websites or information you may obtain from them. ## CONTENT ON OUR PLATFORM [#content-on-our-platform] * **Devopness Website Content:** We are the owner or the licensee of all intellectual property rights in all of the Website Content on our Platform, and in the material published on it. Those works are protected by copyright laws and treaties around the world. All such rights are reserved. You may download Website Content from our Platform for your personal use and you may draw the attention of others within your organization to Website Content posted on our Platform. You must not modify any Devopness Website Content you download. * **User Content you upload to or through our Platform must be the following:** (i) accurate (where it states facts); (ii) be genuinely held (where it states opinions); and comply with the law applicable in English. * **User Content you upload to or through our Platform must not:** (i) contain any material which is defamatory of anyone or could bully, insult, intimidate, discriminate or humiliate someone; (ii) be unlawful; (iii) promote sexually explicit material, selling, or disseminating pornography or other erotic material, regardless of its purpose; (iv) promote violence; (v) infringe any copyright, database right or trade mark; (vi) be likely to deceive any person; (vii) give the impression that the Services originates from us or another person for which you do not have authority from; (viii) contain any advertising or promotion for another company and/ or site; and (ix) knowingly introduce viruses, trojans, worms, logic bombs or other material that is malicious or technologically harmful.(x) attempt unauthorized and/or illegal access of computers, networks and/or accounts not belonging to party seeking access; (xi) provide False Data on any Contract or Application: including fraudulent use of credit card numbers; (xii) send of any unsolicited or promotional material (SPAM) or unauthorized advertising; (xiii) attack and/or attempts to steal money and/or identity, by getting others to reveal personal information, such as credit card numbers, bank information, and/or passwords on websites that pretend or represent to be legitimate; and (xiv) use Devopness in a manner inconsistent with any applicable laws or regulations. * **Do not reverse engineer any of the Platform.** You will not reverse engineer or otherwise attempt to derive or obtain information about the functioning, manufacture or operation of the Platform. Nor will you attempt to modify, translate, or create derivative works based on the Platform; or copy (save for archival purposes), rent, lease, distribute, pledge, assign or otherwise transfer or encumber rights to the Platform. * **Internal business use only.** You acknowledge and agree that you can only use the Platform for internal business purposes only and may not transfer, sell, distribute, lease, sublease, assign or license to any third parties. * **You must not attempt to gain unauthorized access.** Whether this is to our Platform, the servers on which our Platform is stored or any servers, computer or database connected to our Platform. You must not attack our Platform via a denial-of-service attack or a distributed denial-of service attack. We will report any such breach to the relevant law enforcement authorities and we will cooperate with those authorities by disclosing your identity to them. In the event of such a breach, your right to use our Platform will cease immediately. * **Server Security.** You are solely responsible for maintaining the security of your servers that are provisioned, connected or managed through our Platform. Devopness shall have no liability for any security breaches or data breaches of your servers, even if those servers were initially created and provisioned by our Platform. Devopness does not guarantee the security of any of your servers, even if those servers were initially created and provisioned by our Platform. * **Backup.** You are solely responsible for the preservation of the data you save on physical, and virtual servers and cloud services managed through our Platform (the “Data”). Devopness shall have no responsibility to preserve Data and shall have no liability for any Data that may be lost. ## INTELLECTUAL PROPERTY [#intellectual-property] * **Our Platform.** We are the owner or the licensee of all intellectual property rights in the Platform including any modifications and improvements, whether made by us or suggested by you. Those works are protected by copyright laws and treaties around the world. All such rights are reserved. We provide you with a worldwide, non-exclusive, non-transferable, non-sublicensable, revocable limited term license for internal use only to use the Platform in accordance with these Terms. Such a right to use the Platform and any User Content on the Platform will expire at the point your subscription ends or when we terminate the Agreement, whichever is sooner. * **Data you transmit through the Platform.** All documents, messages, logos, images, files and other information you transmit through our Platform, will remain yours and you shall retain all rights, titles and interest in those. You do however provide us with a worldwide, royalty-free, non-exclusive, transferable and sublicensable right to use your data to improve our Platform. * **User Content.** We will retain all intellectual property rights in the User Content on the Platform, save for those created by you and our other users. We grant to you a non-exclusive license to make, use and share User Content publicly with other users via the Platform. Any User Content created by you are private, and it is your choice as to whether or not you share these with the Devopness community publically to use, share and modify. You grant to us a worldwide, royalty-free, non-exclusive, transferable and sub-licensable right to use, modify and distribute any User Content you choose to share on our Platform. You acknowledge that where we create User Content materially similar to or the same as any User Content you have made public on our Platform, you will have no claims against us including for infringement or misappropriation. ## CANCELLATION, TERMINATION AND SUSPENSION [#cancellation-termination-and-suspension] * **Termination of your subscription term.** Your subscription will start on the date you sign up as a user of the Platform and agree to these Terms. Your access to the Platform will continue until the earlier of you canceling your subscription; we terminate your right to access the Platform; or you commit a material breach of these Terms. All fees owed to Devopness and charges accrued before such termination shall be immediately due and payable. * **Where you wish to terminate your subscription.** You can do this via the Platform or by email at: [legal@devopness.com](mailto\:legal@devopness.com). * **Deletion of data.** We will only retain your data for as long as we need it. We will contact you by email 30 days before deactivating and deleting your account. * **Survival of important terms.** Please note that all rights under this Agreement, which by nature should survive termination, will, including Indemnity, Liability, Governing Law, Notices and Intellectual Property. ## INDEMNITY [#indemnity] * **Your indemnity to us.** You agree to indemnify us, our affiliates, directors, officers and employees against all loss, costs, damages, liabilities and expenses that arise out of your breach of these Terms and/ or use of the Platform. ## LIABILITY [#liability] * **We do not limit any losses that we are not allowed to limit:** We do not exclude or limit in any way our liability to you where it would be unlawful to do so including death or personal injury caused by our negligence. * **What we do limit:** We exclude all implied conditions, warranties, representations or other terms that may apply to our Platform or any Services on it. We will not be liable to you for any loss or damage, whether in contract, tort (including negligence), breach of statutory duty, or otherwise, even if foreseeable, arising under or in connection with the use of, or inability to use, our Platform; or use of or reliance on any Services displayed on our Platform. In particular, we will not be liable for loss of profits, sales, business, or revenue; business interruption; loss of anticipated savings; loss of business opportunity, goodwill or reputation; or any indirect or consequential loss or damage. * **No Services guarantees.** The Platform is provided “as is”. We make no guarantee as to the quality of the Platform and its suitability for your individual purposes, and will not be liable in the event you do not undertake your own prior due diligence. * **Severability.** Each of the paragraphs of these terms operates separately. If any court or relevant authority decides that any of them are unlawful or unenforceable, the remaining paragraphs will remain in full force and effect. ## NOTICES [#notices] * **Where do we issue notices to you.** We will issue all notices to you via the Platform save for any that will materially impact your rights or your use of the Platform which we will email to you, via the email you use to subscribe to the Platform. * **Complaints and legal disputes.** Where you have any complaints, are subject to insolvency (or similar) proceedings or wish to issue legal proceedings against us, you should send notice of these to [legal@devopness.com](mailto\:legal@devopness.com). ## GOVERNING LAW [#governing-law] * **What laws apply to these Terms?** These terms are governed by English law and you can bring legal proceedings in the English courts. However if you are a consumer you may also benefit from any mandatory provisions of the law of the country in which you are resident. Nothing in these Terms affects your rights as a consumer to rely on such mandatory provisions of local law. * **Changes to these Terms.** As our service grows and improves, we might have to make changes to these Terms. We will do this by uploading the latest version with a date confirming when they went live. Effective 01 February 2023 # List Links Learn how to view existing links that associate resources (such as SSH Keys to Servers or Servers to Applications) within your environment. 1. On Devopness, navigate to a project then select an environment 2. Open the resource where links are managed (for example, `SSH Keys` or `Applications`) 3. In the resource details view, click the `LINKS` tab to see existing links 4. Use the list to verify which resources are linked together 5. Click a linked item to view its details or manage the association # Install Devopness MCP Server on AntiGravity This guide walks you through installing and configuring the Devopness MCP server on [AntiGravity](https://antigravity.google/) by Google. ## Prerequisites [#prerequisites] 1. [AntiGravity](https://antigravity.google/) installed on your machine 2. A Devopness account with a Personal Access Token ## How Devopness integrates with AntiGravity [#how-devopness-integrates-with-antigravity] Devopness provides a remote MCP server that AntiGravity connects to through its native HTTP support. Once configured, the Devopness tools become available in the AntiGravity agent panel. ## Configure the MCP server [#configure-the-mcp-server] 1. Open the AntiGravity agent panel 2. Click the **"..."** dropdown at the top of the editor panel 3. Select **MCP Servers** to open the MCP Store 4. Click **Manage MCP Servers**, then select **View raw config** 5. This opens the configuration file located at: * **macOS/Linux:** `~/.gemini/antigravity/mcp_config.json` * **Windows:** `C:\Users\\.gemini\antigravity\mcp_config.json` 6. Add the following configuration, replacing `YOUR_PERSONAL_ACCESS_TOKEN` with your Devopness Personal Access Token: ```json { "mcpServers": { "devopness": { "serverUrl": "https://mcp.devopness.com/mcp/", "headers": { "Authorization": "Bearer YOUR_PERSONAL_ACCESS_TOKEN" } } } } ``` 7. Save the file. AntiGravity automatically reloads the configuration. ## Activate and verify the connection [#activate-and-verify-the-connection] 1. Open the **MCP Servers** panel from the **"..."** dropdown 2. Check the status indicator next to the Devopness server 3. Verify that the Devopness tools are listed and available ## Use the MCP server [#use-the-mcp-server] In the AntiGravity agent panel, try a prompt such as: * "List my Devopness projects" * "Show the servers in my production environment" * "Deploy my application to staging" ## Troubleshooting [#troubleshooting] * **Server not appearing:** Verify that the JSON syntax in `mcp_config.json` is valid. Save and reopen the MCP Servers panel. * **Authentication errors:** Verify that your Personal Access Token is correct and has not expired. * **Tool limit:** For optimal performance, keep the total number of enabled MCP tools under 50. * **Alternative configuration:** If the native `serverUrl` approach has issues, try using the `mcp-remote` proxy instead. This requires [Node.js](https://nodejs.org/) to be installed: ```json { "mcpServers": { "devopness": { "command": "npx", "args": [ "-y", "mcp-remote", "https://mcp.devopness.com/mcp/", "--header", "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" ] } } } ``` # Install Devopness MCP Server on Claude Code This guide walks you through installing and configuring the Devopness MCP server on [Claude Code](https://claude.com/claude-code) by Anthropic. ## Prerequisites [#prerequisites] 1. An active Devopness account 2. [Claude Code](https://claude.com/claude-code) installed on your machine ```bash curl -fsSL https://claude.ai/install.sh | bash ``` ## How Devopness integrates with Claude Code [#how-devopness-integrates-with-claude-code] Devopness provides a remote MCP server that Claude Code connects to. Devopness offers two authentication methods: * **OAuth 2.0:** Browser-based authentication flow * **API Token:** Header-based authentication using Personal Access Tokens Once configured, you'll have access to Devopness tools directly from the Claude Code command line interface. ## Configure the MCP server [#configure-the-mcp-server] ### Method 1: OAuth Authentication [#method-1-oauth-authentication] **Step 1: Add the MCP server** ```bash claude mcp add --transport http devopness https://mcp.devopness.com/mcp/ ``` This command registers the Devopness MCP server with Claude Code. **Step 2: Authenticate via browser** 1. Start Claude Code: ```bash claude ``` 2. Open the MCP management interface: ``` > /mcp ``` 3. Select the **devopness** server from the list 4. Choose **Authenticate** 5. Your default browser will open to the Devopness authorization page 6. Review the requested permissions and click **Authorize** 7. The browser will show a success message and you'll be redirected back to Claude Code 8. Verify authentication by running `/mcp` again - you should see: ``` Status: ✔ connected Auth: ✔ authenticated Tools: Multiple Devopness tools available ``` ### Method 2: API Token Authentication [#method-2-api-token-authentication] **Step 1: Create a Personal Access Token** Create a Personal Access Token in your Devopness account. See [Add Personal Access Token](/docs/api-tokens/personal-access-tokens/add-personal-access-token) for instructions. **Step 2: Add the server with authentication header** ```bash claude mcp add --transport http devopness https://mcp.devopness.com/mcp/ \ --header "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" ``` Replace `YOUR_PERSONAL_ACCESS_TOKEN` with the token you generated in Step 1. ## Activate and verify the connection [#activate-and-verify-the-connection] 1. Start Claude Code if not already running: ```bash claude ``` 2. Check the MCP server status: ``` > /mcp ``` 3. Expected output for a successfully configured server: ``` Server name: devopness Status: ✔ connected Auth: ✔ authenticated Tools: Multiple Devopness tools available ``` 4. If you see `needs authentication`, select the server and choose **Authenticate** to complete the OAuth flow ## Use the MCP server [#use-the-mcp-server] Once connected and authenticated, you can use natural language to interact with your Devopness infrastructure. Try these example prompts: **Project and Environment Management:** * "List all my Devopness projects" * "Show the environments in the \[project name] project" * "What servers are running in my production environment?" **Application Deployment:** * "Deploy my application to staging" * "Show recent deployments for \[application name]" * "What's the status of my latest deployment?" **Server Management:** * "List all servers in production" * "Show server details for \[server name]" * "What services are running on \[server name]?" **Infrastructure Monitoring:** * "Show me the status of all my applications" * "List all SSL certificates about to expire" * "What cron jobs are configured in production?" ## Troubleshooting [#troubleshooting] * **Server shows "needs authentication" status:** Run the `/mcp` command, select the Devopness server, and choose **Authenticate** to complete the OAuth flow. * **OAuth callback errors or timeout:** Verify you can access `https://mcp.devopness.com` from your browser, check if your firewall is blocking the OAuth callback on localhost, or try specifying a different port with `--callback-port 8081`. Use the **Re-authenticate** option in the `/mcp` menu if needed. * **API Token authentication errors:** Ensure you're using the complete token with the `Bearer` prefix in the header. Check if your Personal Access Token is still valid in your Devopness account settings. * **Tools not appearing:** Restart Claude Code (`claude` command), verify authentication status shows `✔ authenticated`, and ensure connection shows `✔ connected`. Try the **Re-authenticate** option or remove and re-add the server via `/mcp` if necessary. * **Claude Code responds without using Devopness data:** Ensure the MCP server status is `✔ connected` and `✔ authenticated`. Be more specific in your prompts (e.g., "List my Devopness projects" instead of "What projects do I have?"). Verify you have actual resources in your Devopness account. # Install Devopness MCP Server on Codex CLI Connect Codex CLI to the Devopness MCP server and authorize access with your Devopness account. ## Prerequisites [#prerequisites] 1. An active Devopness account 2. [Codex CLI](https://developers.openai.com/codex/cli) installed on your machine Verify that Codex CLI is available: ```bash codex --version ``` ## Configure the MCP server [#configure-the-mcp-server] Add the Devopness remote MCP server: ```bash codex mcp add devopness --url https://mcp.devopness.com/mcp/ ``` Codex detects OAuth support and opens the Devopness authorization flow in your browser. 1. Sign in to your Devopness account 2. Review and authorize the requested access 3. Return to the terminal and wait for the successful login message If the authorization flow does not start or was interrupted, run: ```bash codex mcp login devopness ``` ## Verify the connection [#verify-the-connection] List the configured MCP servers: ```bash codex mcp list ``` Verify that `devopness` is enabled and its authentication status is `OAuth`. Inspect the server configuration: ```bash codex mcp get devopness ``` The output must show the streamable HTTP transport and the Devopness MCP URL. ## Use the MCP server [#use-the-mcp-server] Start a new Codex session so it loads the MCP server: ```bash codex ``` Ask Codex to use the configured server explicitly: ```text Use the devopness MCP server to return my current Devopness user profile. ``` Codex should call the Devopness user profile tool and return the authenticated user's details. You can then use prompts such as: * "Use Devopness to list my projects" * "Use Devopness to show the environments in the example project" * "Use Devopness to list the servers in production" ## Troubleshooting [#troubleshooting] * **OAuth did not start:** Run `codex mcp login devopness` * **OAuth callback failed:** Allow connections to the temporary localhost callback URL and verify that your browser can access `https://mcp.devopness.com` * **Server is not available in a session:** Exit and restart Codex after adding or authenticating the server * **Authentication is stale:** Run `codex mcp logout devopness`, then `codex mcp login devopness` * **Other MCP servers fail during startup:** Run `codex mcp list` and verify `devopness` separately. A warning for another server does not mean the Devopness connection failed * **Devopness tools are not used:** Name the `devopness` MCP server explicitly in the prompt and verify the OAuth status with `codex mcp list` ## Expected result [#expected-result] Codex CLI can call Devopness MCP tools with the permissions of your authorized Devopness account. To remove the connection, run: ```bash codex mcp remove devopness ``` # Install Devopness MCP Server on Gemini CLI This guide walks you through installing and configuring the Devopness MCP server on [Gemini CLI](https://github.com/google-gemini/gemini-cli) by Google. ## Prerequisites [#prerequisites] 1. [Gemini CLI](https://github.com/google-gemini/gemini-cli) installed on your machine 2. A Devopness account with a Personal Access Token ## How Devopness integrates with Gemini CLI [#how-devopness-integrates-with-gemini-cli] Devopness provides a remote MCP server that Gemini CLI connects to through its native HTTP support. Once configured, the Devopness tools become available in your Gemini CLI sessions. ## Configure the MCP server [#configure-the-mcp-server] ### Option A: Edit the settings file [#option-a-edit-the-settings-file] 1. Open the Gemini CLI settings file at `~/.gemini/settings.json` 2. Add the following configuration, replacing `YOUR_PERSONAL_ACCESS_TOKEN` with your Devopness Personal Access Token: ```json { "mcpServers": { "devopness": { "httpUrl": "https://mcp.devopness.com/mcp/", "headers": { "Authorization": "Bearer YOUR_PERSONAL_ACCESS_TOKEN" } } } } ``` 3. Save the file You can also create a project-level configuration by placing a `.gemini/settings.json` file in your project root directory. ### Option B: Use the CLI command [#option-b-use-the-cli-command] Run the following command, replacing `YOUR_PERSONAL_ACCESS_TOKEN` with your Devopness Personal Access Token: ```bash gemini mcp add \ --transport http \ --header "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" \ -s user \ devopness \ https://mcp.devopness.com/mcp/ ``` ## Activate and verify the connection [#activate-and-verify-the-connection] 1. Start or restart Gemini CLI 2. Run the `/mcp` command to check the server status 3. The output displays all configured servers with their connection state: **CONNECTED**, **CONNECTING**, or **DISCONNECTED** 4. Verify that the Devopness server shows as **CONNECTED** and its tools are listed ## Use the MCP server [#use-the-mcp-server] In a Gemini CLI session, try a prompt such as: * "List my Devopness projects" * "Show the servers in my production environment" * "Deploy my application to staging" ## Troubleshooting [#troubleshooting] * **Server not connecting:** Test the MCP server endpoint independently with `curl https://mcp.devopness.com/mcp/` to verify connectivity. * **Authentication errors:** Verify that your Personal Access Token is correct and has not expired. * **Debug mode:** Run Gemini CLI with `--debug` for verbose output, or press **F12** to open the debug console in interactive mode. * **Configuration priority:** When both `httpUrl` and `url` are set, `httpUrl` takes priority. Use `httpUrl` for the Devopness MCP server. # MCP Servers The Devopness MCP (Model Context Protocol) server lets AI assistants and agents manage your cloud infrastructure using natural language. Connect one or more IDEs, CLIs, or agent platforms to deploy applications, create servers, manage environments, and more. ## Supported editors and tools [#supported-editors-and-tools] Choose your editor or AI tool below for step-by-step installation instructions: * [AntiGravity](/docs/mcp/antigravity) * [Claude Code](/docs/mcp/claude-code) * [Codex CLI](/docs/mcp/codex-cli) * [Gemini CLI](/docs/mcp/gemini-cli) * [JetBrains AI](/docs/mcp/jetbrains) * [OpenCode](/docs/mcp/opencode) * [Trae](/docs/mcp/trae) * [Warp](/docs/mcp/warp) * [Windsurf](/docs/mcp/windsurf) * [Zed](/docs/mcp/zed) # Install Devopness MCP Server on JetBrains AI This guide walks you through installing and configuring the Devopness MCP server on [JetBrains IDEs](https://www.jetbrains.com/) (IntelliJ IDEA, WebStorm, PyCharm, and others) using the AI Assistant plugin. ## Prerequisites [#prerequisites] 1. A JetBrains IDE version **2025.1** or later (IntelliJ IDEA, WebStorm, PyCharm, etc.) 2. The [AI Assistant](https://plugins.jetbrains.com/plugin/22282-ai-assistant) plugin installed and activated 3. A Devopness account with a Personal Access Token ## How Devopness integrates with JetBrains [#how-devopness-integrates-with-jetbrains] Devopness provides a remote MCP server that JetBrains IDEs connect to through the AI Assistant plugin. Once configured, the Devopness tools become available in the AI chat when using Codebase mode. ## Configure the MCP server [#configure-the-mcp-server] 1. Open your JetBrains IDE and navigate to **Settings > Tools > AI Assistant > Model Context Protocol (MCP)** 2. Click the **Add (+)** button and select **As JSON** from the dropdown 3. Paste the following configuration, replacing `YOUR_PERSONAL_ACCESS_TOKEN` with your Devopness Personal Access Token: ```json { "mcpServers": { "devopness": { "url": "https://mcp.devopness.com/mcp/", "headers": { "Authorization": "Bearer YOUR_PERSONAL_ACCESS_TOKEN" } } } } ``` 4. Click **OK**, then **Apply** to save the configuration ## Activate and verify the connection [#activate-and-verify-the-connection] 1. In the **MCP** settings table, check the **Status** column next to the Devopness server 2. A connected status indicates the server is running 3. Click the status icon to view the list of available Devopness tools 4. In the AI chat, ensure **Codebase mode** is toggled on, as MCP tools are only available in this mode ## Use the MCP server [#use-the-mcp-server] Open the AI chat in Codebase mode and try a prompt such as: * "List my Devopness projects" * "Show the servers in my production environment" * "Deploy my application to staging" ## Troubleshooting [#troubleshooting] * **Server not connecting:** Click the **Reconnect** button in the MCP settings if the connection drops. * **Authentication errors:** Verify that your Personal Access Token is correct and has not expired. * **Check logs:** Go to **Help > Show Log in Explorer/Finder** and look in the `mcp` folder within the logs directory. * **MCP tools not appearing in chat:** Make sure **Codebase mode** is enabled in the AI chat. MCP tools are not available in the default chat mode. * **Plugin version:** Ensure the AI Assistant plugin is version **251.26094.80.5** or later. # Install Devopness MCP Server on OpenCode This guide walks you through installing and configuring the Devopness MCP server on [Opencode](https://opencode.ai/) by Anoma.ly. ## Prerequisites [#prerequisites] 1. [OpenCode](https://www.opencode.ai/) installed on your machine 2. An active Devopness account ## How Devopness integrates with OpenCode [#how-devopness-integrates-with-opencode] Devopness provides a remote MCP server that OpenCode connects to through its native HTTP support. Once configured, the Devopness tools become available in your OpenCode CLI sessions. ## Installation [#installation] 1. Open your terminal and run `opencode mcp add` 2. Follow the interactive prompts to add your Devopness MCP server to your OpenCode config: * **Location** choose the location `Global` * **Enter MCP server name** Enter MCP name, we recommend `devopness` * **Select MCP server type** Choose `remote` * **Enter MCP server URL** Enter MCP URL, use `https://mcp.devopness.com/mcp/` * **Does this server require OAuth authentication?** Choose the option `yes` * **Do you have a pre-registered client ID?** Choose the option `no` 3. run `opencode mcp auth` and choose the `devopness` option 4. Will open a browser window for you to authenticate with your Devopness account, and upon successful authentication, you will be redirected back to your terminal. 5. Restart your terminal 6. You are now authenticated with your Devopness account and can use the Devopness MCP server with your OpenCode CLI sessions. You can check if your MCP server is configured correctly by running `opencode mcp list`, will show a message like this: ```bash MCP servers ✓ devopness connected (OAuth) https://mcp.devopness.com/mcp/ ``` ## Activate and verify the connection [#activate-and-verify-the-connection] 1. Start opencode 2. Run the `/mcp` command to check the server status 3. Type in the popup `devopness` 4. Verify that the Devopness server shows as **devopness connected** ## Use the MCP server [#use-the-mcp-server] In a OpenCode session, try a prompt such as: * "List my Devopness projects" * "Show the servers in my production environment" * "Deploy my application to staging" ## Troubleshooting [#troubleshooting] * **Server not connecting:** Ensure the `url` uses the `https://` prefix and the JSON syntax is valid. * **Authentication errors:** Closes the OpenCode session and run `opencode mcp auth`, and choose the `devopness` option to authenticate again. * **Wrong credentials:** Run `opencode mcp logout` and choose the `devopness` option to remove your credentials and authenticate again. # Install Devopness MCP Server on Trae This guide walks you through installing and configuring the Devopness MCP server on [Trae](https://www.trae.ai/) by ByteDance. ## Prerequisites [#prerequisites] 1. [Trae](https://www.trae.ai/) installed on your machine 2. A Devopness account with a Personal Access Token ## How Devopness integrates with Trae [#how-devopness-integrates-with-trae] Devopness provides a remote MCP server that Trae connects to through its native HTTP support. Once configured, the Devopness tools become available in the Trae AI assistant. ## Configure the MCP server [#configure-the-mcp-server] 1. Click the **Settings** button in the upper-right corner of Trae 2. Navigate to the **MCP** section under Agent settings 3. Click **Add MCP Server**, then select **Manual Configuration** 4. Paste the following configuration, replacing `YOUR_PERSONAL_ACCESS_TOKEN` with your Devopness Personal Access Token: ```json { "mcpServers": { "devopness": { "url": "https://mcp.devopness.com/mcp/", "headers": { "Authorization": "Bearer YOUR_PERSONAL_ACCESS_TOKEN" } } } } ``` 5. Save the configuration You can also configure MCP servers at the project level by creating a `.trae/mcp.json` file in your project root directory. This requires enabling **Settings > Beta > Enable Project MCP** first. ## Activate and verify the connection [#activate-and-verify-the-connection] 1. After saving, the Devopness server should appear in your MCP server list 2. Verify that the status indicator shows the server is active 3. The Devopness tools should now be available in your Trae AI sessions ## Use the MCP server [#use-the-mcp-server] Open a Trae AI session and try a prompt such as: * "List my Devopness projects" * "Show the servers in my production environment" * "Deploy my application to staging" ## Troubleshooting [#troubleshooting] * **Server not connecting:** Ensure the `url` uses the `https://` prefix and the JSON syntax is valid. * **Authentication errors:** Verify that your Personal Access Token is correct and has not expired. * **Configuration not loading:** Restart Trae if the MCP connection fails after making configuration changes. # Install Devopness MCP Server on Warp This guide walks you through installing and configuring the Devopness MCP server on [Warp](https://www.warp.dev/). ## Prerequisites [#prerequisites] 1. [Warp](https://www.warp.dev/) installed on your machine 2. [Node.js](https://nodejs.org/) installed (required for the `npx` command) 3. A Devopness account with a Personal Access Token ## How Devopness integrates with Warp [#how-devopness-integrates-with-warp] Warp does not natively support remote HTTP MCP servers with custom headers. The connection is established through `mcp-remote`, a lightweight proxy that bridges Warp to the Devopness remote MCP server. ## Configure the MCP server [#configure-the-mcp-server] 1. Open Warp and navigate to **Settings > Personal > MCP Servers** 2. Click **Add Server**, then select **CLI Server** 3. Paste the following configuration, replacing `YOUR_PERSONAL_ACCESS_TOKEN` with your Devopness Personal Access Token: ```json { "mcpServers": { "devopness": { "command": "npx", "args": [ "-y", "mcp-remote", "https://mcp.devopness.com/mcp/", "--header", "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" ] } } } ``` 4. Save the configuration ## Activate and verify the connection [#activate-and-verify-the-connection] 1. In the MCP Servers settings page, check the box to auto-start the server on launch, or start it manually 2. Look for **Running** displayed above the MCP server name to confirm the connection is active 3. The Devopness tools should now be available in your Warp AI sessions ## Use the MCP server [#use-the-mcp-server] In a Warp AI session, try a prompt such as: * "List my Devopness projects" * "Show the servers in my production environment" * "Deploy my application to staging" ## Troubleshooting [#troubleshooting] * **Server not starting:** Verify that Node.js is installed by running `node --version` in your terminal. * **Authentication errors:** Verify that your Personal Access Token is correct and has not expired. * **Check logs:** Click the **log file** link in the MCP server settings for detailed error messages. * **Cached credentials:** If authentication issues persist after changing your token, try removing cached MCP credentials by running `rm -rf ~/.mcp-auth`. # Install Devopness MCP Server on Windsurf This guide walks you through installing and configuring the Devopness MCP server on [Windsurf](https://windsurf.com/) by Codeium. ## Prerequisites [#prerequisites] 1. [Windsurf](https://windsurf.com/) installed on your machine 2. A Devopness account with a Personal Access Token ## How Devopness integrates with Windsurf [#how-devopness-integrates-with-windsurf] Devopness provides a remote MCP server that Windsurf connects to through its native HTTP support. Once configured, the Devopness tools become available in the Cascade AI assistant panel. ## Configure the MCP server [#configure-the-mcp-server] 1. Open the MCP configuration file at: * **macOS/Linux:** `~/.codeium/windsurf/mcp_config.json` * **Windows:** `%USERPROFILE%\.codeium\windsurf\mcp_config.json` You can also access this file from Windsurf by clicking the **MCP icon** in the top-right of the Cascade panel, then selecting **View raw config (JSON)**. 2. Add the following configuration, replacing `YOUR_PERSONAL_ACCESS_TOKEN` with your Devopness Personal Access Token: ```json { "mcpServers": { "devopness": { "serverUrl": "https://mcp.devopness.com/mcp/", "headers": { "Authorization": "Bearer YOUR_PERSONAL_ACCESS_TOKEN" } } } } ``` 3. Save the file ## Activate and verify the connection [#activate-and-verify-the-connection] 1. Open Windsurf and navigate to **Windsurf Settings > Cascade > MCP Servers** 2. Click the **refresh button** to reload the MCP server configuration 3. Confirm that the **devopness** server appears in the list 4. Verify that the Devopness tools are listed under the server entry ## Use the MCP server [#use-the-mcp-server] Open the Cascade panel and try a prompt such as: * "List my Devopness projects" * "Show the servers in my production environment" * "Deploy my application to staging" ## Troubleshooting [#troubleshooting] * **Server not appearing:** Check that the JSON syntax in `mcp_config.json` is valid. A missing comma or bracket can prevent the server from loading. * **Authentication errors:** Verify that your Personal Access Token is correct and has not expired. * **Check logs:** Review the Windsurf logs at `~/.codeium/windsurf/logs` for detailed error messages. * **Tool limit:** Windsurf has a limit of 100 total MCP tools. If you have many MCP servers configured, disable tools you do not need. # Install Devopness MCP Server on Zed # Installing and Using the Devopness MCP Server in Zed [#installing-and-using-the-devopness-mcp-server-in-zed] This guide explains how to configure and use the **Devopness Model Context Protocol (MCP) server** in the Zed editor. By completing these steps, you allow Zed’s AI features to access **real Devopness context and actions**, such as projects, environments, and applications. > ⚠️ **Prerequisites** > > * Zed installed > * Node.js and `npx` available > * A Devopness Personal Access Token (PAT) *** ## 🧠 What is MCP in Zed [#-what-is-mcp-in-zed] Zed uses the **Model Context Protocol (MCP)** to connect to external context servers. An MCP server: * Exposes structured data and tools * Is invoked by a language model (LLM) configured in Zed * Does **not** act autonomously Devopness provides an MCP server that exposes your Devopness resources (projects, environments, applications, pipelines) as tools and context that a configured LLM can use inside Zed. > ℹ️ **Important** > Devopness is **not an agent** in Zed. > It is an MCP server whose tools are used by a language model configured in the editor. *** ## ⚙️ Prerequisites [#️-prerequisites] Ensure the following are installed and available before continuing. ### ✔️ Zed editor [#️-zed-editor] Install or update Zed from: [https://zed.dev](https://zed.dev) ### ✔️ Node.js and `npx` [#️-nodejs-and-npx] Zed uses `npx` to run the remote MCP client. Verify installation: ```bash node --version npx --version ``` If not installed, download from: [https://nodejs.org](https://nodejs.org) ### ✔️ Devopness Personal Access Token [#️-devopness-personal-access-token] Generate a **Personal Access Token (PAT)** from your Devopness account. This token authenticates the MCP connection. *** ## 🛠️ Configuring the Devopness MCP Server [#️-configuring-the-devopness-mcp-server] In Zed, **configuration** and **activation** are separate steps. You must configure the MCP server first, then activate it. *** ### Step 1 — Configure the MCP server [#step-1--configure-the-mcp-server] Choose **one** of the following methods. *** #### Option A — Edit the Zed configuration file [#option-a--edit-the-zed-configuration-file] 1. Open Zed 2. Open **Settings** * macOS: `Cmd + ,` * Linux / Windows: `Ctrl + ,` 3. Navigate to **AI → Context Servers** 4. Click **Edit in settings.json** 5. Add the following block: ```json { "context_servers": { "devopness": { "command": "npx", "args": [ "-y", "mcp-remote", "https://mcp.devopness.com/mcp/", "--header", "Authorization: Bearer ${DEVOPNESS_PERSONAL_ACCESS_TOKEN}" ], "env": { "DEVOPNESS_PERSONAL_ACCESS_TOKEN": "dvpn_your_real_token_here" } } } } ``` Edit in settings.json *** #### Option B — Use the Command Palette [#option-b--use-the-command-palette] 1. Press **Ctrl + Shift + P** 2. Run **`agent:add context server`** agent context server 3. Paste the same JSON configuration shown above consfigure-remote 4. Save > 📌 **Options A and B are alternatives.** > Use **only one** of them. *** ### Step 2 — Activate the Devopness MCP server (required) [#step-2--activate-the-devopness-mcp-server-required] After configuration, the MCP server must be enabled. 1. Open the **Agent Panel** * Shortcut: **Ctrl + Shift + ?** * Or menu: **View → AI Settings** 2. Locate **Model Context Protocol (MCP)** View → AI Settings 3. Enable **Devopness** using the toggle > ⚠️ Configuration alone is not enough. > The MCP server must be explicitly activated. *** ## ✅ Verifying the MCP Connection [#-verifying-the-mcp-connection] After configuration and activation: 1. Open **Ctrl + Shift + ?** or **View → AI Settings** 2. Under **Model Context Protocol**, you should see: * `devopness` * Status: **active** * A list of available tools (for example: *55 tools*) View → AI Settings If the server appears but does not respond correctly, verify: * Your Personal Access Token * Node.js and `npx` availability * That a language model is configured in Zed *** ## 🤖 Using Devopness Context in Zed [#-using-devopness-context-in-zed] Once active, the Devopness MCP server provides tools that a configured LLM can use. Example prompts: * `List my Devopness projects` * `Show my Devopness environments` * `Fetch my Devopness applications` > ℹ️ If your Devopness account has no resources, empty results are expected. *** ## ⚠️ Common Issues [#️-common-issues] ### No language model configured [#no-language-model-configured] An MCP server requires an active LLM (OpenAI, Anthropic, Ollama, etc.). Configure a language model before testing prompts. ### Generic or fictional responses [#generic-or-fictional-responses] This usually means the LLM responded **without invoking the MCP server**. Ensure: * Devopness is active under **Model Context Protocol** * The token is valid ### `npx: command not found` [#npx-command-not-found] Install Node.js and ensure `npx` is available in your system PATH. ### Authentication errors [#authentication-errors] Double-check your Devopness Personal Access Token. *** ## 📌 Summary [#-summary] * Devopness provides an **MCP server**, not an autonomous agent * MCP servers must be **configured and activated** * A language model is required to use MCP tools * Once active, Devopness context becomes available to Zed’s AI features This setup enables Zed to interact with **real Devopness data**, improving accuracy and usefulness when working with Devopness-related workflows. # API Tokens API Tokens let tools and automations authenticate securely when working with the Devopness API. ## Types of API Tokens [#types-of-api-tokens] ### Personal Access Tokens [#personal-access-tokens] A Personal Access Token uses your user identity and inherits your permissions. Use it when automation should behave like a user. * It can access resources your user can access * It is useful for quick scripts and local tooling * It can work across multiple projects where the user has access ### Project API Tokens [#project-api-tokens] Project API Tokens are scoped to one project and safer for shared automation. * Access is limited to resources in that project * RBAC controls what each token can do * User-level endpoints, such as `/users` details and invitations, are not included ## Which token should I use [#which-token-should-i-use] Use Personal Access Tokens when: * You need one-off user-like access * A task is personal and temporary Use Project API Tokens when: * A service needs recurring access to one project * Multiple people share the automation * You want least-privilege production-safe access When you can, prefer `Project API Tokens` to keep permission scope small. ## Using Devopness MCP [#using-devopness-mcp] API tokens can be created and managed through Devopness MCP. Name the organization, project, and token type so the agent targets the right resource, and confirm each operation completes with a clear success signal. * "In organization `acme-inc`, project `acme-platform`, create a project API token for the CI pipeline, then return the token and its scope so I can store it." * "List my personal access tokens and tell me how many are active." * "Revoke the `ci-deploy` project API token in `acme-inc`/`acme-platform` and confirm it is no longer active." You are done when the agent returns the created token or an updated status that matches the operation (created, listed, or revoked). ## Practical example [#practical-example] A `ci-deploy` pipeline needs to deploy one application each time you push to git: * Create a **Project API Token** scoped to the `acme-platform` project * Give it a deploy-only role so it can trigger deploys but not change other resources * Store the token value once at creation time and use it in the automation This keeps the token from being able to act like a full user or reach resources outside that project. # Add a Network Rule Add network rules to control incoming and outgoing network traffic that is allowed to and from your servers, based on network port and source/destination IP address range. 1. On Devopness, navigate to a project then select an environment 2. Find the `Network Rules` card 3. Click `View` in the `Network Rules` card to see a list of existing `Network Rules` 4. On the upper-right corner of the list click `ADD NETWORK RULE` 5. Follow the prompts then click `CONFIRM` 6. In the `Network Rules` list, the recently create network rule can be seen * A new deployment is required for your changes to take effect * Follow the guide [Run a Pipeline](/pipelines/run-pipeline) # Network Rules Manage your firewall’s network rules # Add a Network Add a network to your environment when you need to define custom network topology. Resources (such as Servers and Applications) deployed to different networks, will be completely isolated from each other. 1. On Devopness, navigate to a project then select an environment 2. Find the `Networks` card 3. Click `View` in the `Networks` card to see a list of existing `Networks` 4. On the upper-right corner of the list click `ADD NETWORK` 5. Select a `Cloud Provider` 6. Select a `Credential` > If no credential is listed or you want to use a different one, click `Create a new credential` and follow the guide [Add a Credential](/credentials/add-credential) 7. Follow the prompts then click `CONFIRM` 8. Wait for the `network:provision` action to be completed * If you want to add a server to the `Network`, it is required to first follow the guide [Add a Subnet](/subnets/add-subnet) # Networks Learn how to provision and manage cloud networks, also known as Virtual Private Clouds (VPCs) # Remove a Network Learn how to remove a network when it's no longer needed 1. On Devopness, navigate to a project then select an environment 2. Find the `Networks` card 3. Click `View` in the `Networks` card, to see a list of existing `Networks` 4. In the list of networks, find the network you want to remove and click the `NAME` of the network 5. On the upper-right corner of the network details view, click `REMOVE` 6. Follow the prompts then click `REMOVE NETWORK` 7. In the `Networks` list, the recently removed `Network` will be gone # Add an Organization Create an organization to group projects, members, and permissions. ## Goal [#goal] Add the organization before you create projects or invite members. ## What you need [#what-you-need] ### Name [#name] A unique organization name. This becomes part of your URL slug, like `/@acme`. ### Organization role (optional) [#organization-role-optional] Assign a role if other team members should help manage the organization. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Create an organization named `acme-platform`" * "Add a new client organization called `northwind`" * "Create an organization for the `design-studio` team" ## After you save [#after-you-save] * The organization appears in your organization list * You can create projects, invite members, and assign roles in it ## Verify [#verify] * The organization appears with the expected name * You can open it and add projects or members ## Common issues [#common-issues] * You do not see `Add Organization`: confirm you have permission to create organizations * The organization name is already taken: choose a unique name ## What to do next [#what-to-do-next] * [Organizations](/docs/organizations/) overview * [Add a project](/docs/projects/add-project) # Edit an Organization Change an organization's name or settings without moving projects or members. ## Goal [#goal] Update organization details when ownership, team, or permissions change. ## Prerequisites [#prerequisites] * Access to the organization you want to change * Permission to edit organization settings ## What you need [#what-you-need] ### Name [#name] The updated organization name, if it changed. ### Other settings [#other-settings] Update the other organization fields shown in the form. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Rename the organization `acme-labs` to `acme-platform`" * "Update the organization details for `northwind`" * "Change the settings for my current organization" ## After you save [#after-you-save] * The organization shows the updated details * Existing projects and members stay in the same organization ## Verify [#verify] * The organization page shows the new details * Projects and members remain in the same organization ## Common issues [#common-issues] * You cannot save changes: confirm you still have edit permission * Updated fields do not save: check required fields and try again ## What to do next [#what-to-do-next] * [Projects](/docs/projects/) overview * [Roles](/docs/roles/) # Organizations An **organization** is the top level in Devopness. It groups projects, teams, roles, and access settings. ## About [#about] * An organization is for one company, legal entity, or client portfolio * Every organization has a URL slug, like `acme` in `/@acme` * People join through invitation or team membership * Projects, teams, and access rules are set at this level ## Who this is for [#who-this-is-for] * Developers who need one place for shared projects * Team leads managing multiple products, clients, or teams * Founders setting up Devopness before adding environments and applications ## Devopness hierarchy [#devopness-hierarchy] * **Organizations** hold one or more **projects** * **Projects** group environments and resources for one product or client * **Environments** are independent infrastructure inside a project (each with its own servers, applications, credentials, and configuration) * **Applications** connect one git repository (or one folder in a monorepo) to one environment Think of it like this: * **Organization:** one company or agency in Devopness, like `/@acme` * **Project:** one product or client inside that organization * **Environment:** a separate infrastructure setup inside that project, such as `Development`, `Staging`, or `Production`. Dev might use one server; production might use many servers, load balancers, or serverless resources * **Application:** your API, web app, or worker in that environment, linked to a git repository ## Why this exists [#why-this-exists] * Teams, roles, and projects live in one organization * Owners control who can see and change what * You can add more projects later without changing the overall structure ## Start here [#start-here] * Create your first organization and get a stable `/@{slug}` * Confirm it is the one where the project should live * Create your first [project](/docs/projects/) * Add an [environment](/docs/environments/), then [applications](/docs/applications/) inside it * Use [Teams](/docs/teams/) to invite members * Add [Roles](/docs/roles/) to control access ## Who can manage an organization [#who-can-manage-an-organization] * Organization owners * Team members with an organization role that allows managing organization settings * Members with project roles can work in project areas * Members with environment roles can contribute to specific environments ## Typical setup flow [#typical-setup-flow] * Start with one organization for the main legal entity or one agency account * Add one project per major product, portfolio, or client * Inside each project, add environments (`Production`, `Development`, `Staging`, or custom names) as separate infrastructure * Add [applications](/docs/applications/) per environment. Deploy to dev first, then move stable work to staging and production ## Common questions [#common-questions] * Can I see all projects in one place? Yes, select the organization first * Why can't I edit org settings? Check your role and permissions ## What to do next [#what-to-do-next] * [Projects](/docs/projects/) * [Teams](/docs/teams/) and [Roles](/docs/roles/) # Remove an Organization Delete an organization when you no longer need its projects, teams, or resources. Removing an organization is permanent. This action cannot be undone. ## Goal [#goal] Delete the organization and remove its data from Devopness. ## Prerequisites [#prerequisites] * Permission to delete organizations * Required data is backed up or migrated * No active resources still depend on it ## What you need [#what-you-need] * The organization you want to remove * Confirmation that deletion is intentional ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Remove the organization `acme-old` after migrating its projects" * "Delete the client organization `northwind`" Check the organization name before you confirm deletion. ## Verify [#verify] * The organization is gone from the organization list * No active project or team still points to it ## Common issues [#common-issues] * You cannot remove the organization: confirm required data is archived first * Deletion is blocked: confirm you have delete permission for this organization * You need to delete dependent resources first: check for active projects, tokens, or integrations ## What to do next [#what-to-do-next] * [Organizations](/docs/organizations/) overview * [Add an organization](/docs/organizations/add-organization) when you need a new one # Add a Pipeline By adding a pipeline to your environment's resources, you can automate their deployment by using customized pipeline steps. 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card to see a list of existing `Applications` 4. In the list of applications find the application where you want to add a pipeline and click the `NAME` of the application 5. Click the `Pipelines` tab 6. On the upper-right corner of the pipelines tab click `MANAGE` 7. Provide a name to the Pipeline being added. Example: "CI Pipeline" 8. Select an `Operation` > Don't use the `Custom` operation, it is not fully supported yet 9. Provide a value for the `Max parallel actions` field 10. Click `CONFIRM` > A new deployment is required for your changes to take effect. * Follow the guide [Deploy Application](/applications/deploy-application) # Edit a Pipeline Editing a pipeline is crucial as it provides a clear and concise way to identify and differentiate between pipelines in your environment. 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card to see a list of existing `Applications` 4. In the list of applications, find the application with the pipeline you want to edit and click the `NAME` of the application 5. Click the `PIPELINES` tab 6. In the list of pipelines, find the pipeline you want to edit and click the `NAME` of the pipeline 7. On the upper-right corner of the pipeline details view, click `EDIT` 8. Follow the instructions in the pipeline edit form then click `CONFIRM` > A new deployment is required for your changes to take effect. * Follow the guide [Deploy Application](/applications/deploy-application) # Pipelines Use pipelines to automate the deployment of resources in your environment, utilizing both predefined and customizable steps. # Remove a Pipeline Learn how to remove a pipeline when it's no longer needed 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card, to see a list of existing `Applications` 4. In the list of applications, find the application with the pipeline you want to remove and click the `NAME` of the application 5. Click the `Pipelines` tab 6. In the list of pipelines, find the pipeline you want to remove and click the `NAME` of the pipeline 7. On the upper-right corner of the pipeline details view, click `REMOVE` 8. Follow the prompts then click `REMOVE PIPELINE` 9. In the list of pipelines, the recently removed `Pipeline` will be gone # Run a Pipeline Run a deploy pipeline to apply a network rule to a server. A network rule and deploy pipeline were chosen as examples, the steps are the same to run pipelines of all operations in all environment's resources 1. On Devopness, navigate to a project then select an environment 2. Find the `Network Rules` card 3. Click `View` in the `Network Rules` card to see a list of existing `Network Rules` 4. In the list of network rules, find the network rule you want to run a pipeline and click the `NAME` of the network rule 5. Click the `PIPELINES` tab 6. In the list of pipelines, find the deploy pipeline you want to run and click `DEPLOY` 7. Follow the prompts then click `DEPLOY` * The form confirm button will be labeled according to the pipeline operation To run a deploy pipeline at least one server must be linked to the resource. If there are no servers linked to the network rule, follow the guide [Link a server to an application](/applications/link-server-to-application) 8. Wait for the action `network-rule:deploy` to be completed # View a Pipeline Learn how to view the details of a pipeline in your application, including its configuration and steps. 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card to see a list of existing `Applications` 4. In the list of applications, find the application with the pipeline you want to view and click the `NAME` of the application 5. Click the `Pipelines` tab 6. In the list of pipelines, click the `NAME` of the pipeline you want to view 7. Review the pipeline details, including operation, max parallel actions, and associated steps 8. To manage steps, follow the guide [Add Step to Pipeline](/pipelines/steps/add-step) # Add a Project Create a project inside your organization for one product or client. ## Goal [#goal] Add the project before you create environments, teams, or applications. ## Prerequisites [#prerequisites] * You can create projects in the selected organization * The correct organization is selected ## What you need [#what-you-need] ### Name [#name] A name your team will recognize, such as the product or client name. This is how the project appears in lists and navigation. Examples: `acme-platform`, `northwind-portal`, `design-studio` ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme`, create a project named `acme-platform`" * "Add a new project called `northwind` for my client" * "List projects in `/@acme`, then create a project for internal tooling" ## After you save [#after-you-save] * The project appears in your project list for that organization * You can add environments, teams, roles, and applications inside it ## Verify [#verify] * The project appears with the expected name in the correct organization * You can open it and continue with environments or team setup ## What to consider [#what-to-consider] ### One project per product or client [#one-project-per-product-or-client] Use separate projects when products or clients need separate owners, permissions, or release schedules. Use separate **environments** inside one project when you need dev, staging, and production infrastructure for the same product. ## Common issues [#common-issues] * You do not see `Add Project`: confirm you have permission to create projects in this organization * The organization selected is not the one you intended: switch organization before you save * The project name is already taken or invalid: choose a unique name ## What to do next [#what-to-do-next] * [Add an environment](/docs/environments/add-environment) * [List projects](/docs/projects/list-projects) to confirm it appears # Edit a Project Change a project's name or settings when the product, client, or team details change. ## Goal [#goal] Update project details without creating a new project. ## Prerequisites [#prerequisites] * You can edit project settings in the selected organization * The target project exists and you can open it ## What you need [#what-you-need] ### Name [#name] The name for this product or client inside the organization. Use a name your team will recognize in lists and navigation. ### Metadata and settings [#metadata-and-settings] Update the other project fields shown in the form when your team needs a change. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Rename project `acme-old` to `acme-platform` in organization `acme`" * "Update the project settings for `northwind`" * "Show project `design-studio` and update its name" ## After you save [#after-you-save] * The project stays the same in Devopness; only the updated fields change * Existing environments, teams, roles, and applications stay linked to this project ## Verify [#verify] * The project details show the updated name and settings * Environments and applications inside the project are unchanged unless you edited them separately ## Common issues [#common-issues] * You do not see edit actions: confirm your role allows project updates * A new project name conflicts with naming rules: choose a unique name in the organization * Changes are not visible yet: reopen the project view after saving ## What to do next [#what-to-do-next] * [View the project](/docs/projects/view-project) to confirm the updated setup * [Deploy applications](/docs/applications/deploy-application) when you are ready to release again # Projects A **project** in Devopness groups everything for one product or one client inside an organization: environments, applications, teams, and access settings. Use one project per product or client. Do not mix unrelated products in the same project. ## Think of it like this [#think-of-it-like-this] * **Organization:** your company or agency account, like `/@acme` * **Project:** one product or client inside that organization * **Environment:** separate infrastructure inside the project (dev, staging, production) * **Application:** one git repository connected to one environment ## About [#about] * Each project belongs to one organization * A project holds one or more environments, and each environment has its own servers, applications, credentials, and configuration * You can start with one project and add another when you add a second product or a new client ## Who this is for [#who-this-is-for] * Developers who work on more than one product * Team leads who want each product in one clear location * Founders who want simple permissions as the team gets bigger ## Why this exists [#why-this-exists] Projects keep related environments and applications together. They also keep unrelated products or clients separate, so permissions and releases stay clear. ## Relationship to other concepts [#relationship-to-other-concepts] * **Organizations** hold all projects and organization-wide team settings * **Environments** inside a project are fully independent: dev might use one or two servers; production might use many servers, load balancers, or serverless infrastructure * **Applications** live inside one environment each: one git repository (or monorepo folder) with its own deploy settings ## Practical example [#practical-example] A startup creates one project for their main product: * `Production` environment with three applications: `acme/api`, `acme/web`, `acme/worker` * Later adds `Development` and `Staging` with their own servers and applications * Adds a second project for internal tooling when a new product owner joins ## First setup path [#first-setup-path] If you already have an organization: 1. [Add a project](/docs/projects/add-project) 2. [Add an environment](/docs/environments/add-environment), starting with `Production` or `Development` 3. [Add applications](/docs/applications/add-application) in that environment 4. Deploy to dev first, then move stable work to staging and production ## Quick decision rule [#quick-decision-rule] Start with one project until one of these is true: * You run separate unrelated products * You need client-specific teams, permissions, or separate owners * You need independent release schedules for different stacks or clients Use separate **projects** for separate products or clients, not extra environments inside one project. ## Common questions [#common-questions] * **One project or many?** One project per major product or client is a good starting point * **Project vs environment?** Use environments for dev, staging, and production inside one product. Use projects when the product or client is different * **What goes in a project name?** Use a name your team knows, such as the product or client name ## Start here [#start-here] * [Add a project](/docs/projects/add-project) * [List projects](/docs/projects/list-projects) * [Environments](/docs/environments/) # List Projects See which projects you can access in the current organization. ## Goal [#goal] Find the project you need before you open environments, applications, or team settings. ## What you need [#what-you-need] * The correct organization selected * Permission to read projects in that organization ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "List projects in organization `acme`" * "Show all projects I can access in `/@acme`" * "Which projects exist in my current organization?" ## What you see [#what-you-see] * Project names you can open for more detail * All projects available to you in the selected organization ## Verify [#verify] * The list shows the organization you expected * The project you need is listed, or you know you must [add one](/docs/projects/add-project) ## Common issues [#common-issues] * No projects appear: confirm you selected the correct organization * A project is missing: confirm you have access to that project in this organization * You expected more projects: check whether they are in a different organization ## What to do next [#what-to-do-next] * [View a project](/docs/projects/view-project) to inspect environments and access * [Add a project](/docs/projects/add-project) if the one you need does not exist yet # Remove a Project Delete a project when you no longer need it. Removing a project is permanent. This action cannot be undone. This also removes all environments, applications, and related resources inside the project. ## Goal [#goal] Delete the project and stop managing it in Devopness. ## Prerequisites [#prerequisites] * You can delete projects in the selected organization * Team members who use this project know it will be deleted * You saved or moved any data you still need outside Devopness ## What you need [#what-you-need] * The project you want to remove * Confirmation that deletion is intentional ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Remove project `old-demo` from organization `acme`" * "Delete the `northwind-staging` project after confirming it is unused" Check the project name carefully before you confirm deletion. ## Verify [#verify] * The project no longer appears in the [project list](/docs/projects/list-projects) * Team access to that project is removed * Environments and applications in that project are no longer available in Devopness ## Common issues [#common-issues] * You cannot remove the project: confirm you have delete permission for the project * Deletion is blocked: remove or archive dependent resources first if required * You deleted the wrong project: this cannot be undone; restore from backups outside Devopness if needed ## What to do next [#what-to-do-next] * [List projects](/docs/projects/list-projects) to see remaining projects * [Add a project](/docs/projects/add-project) when you need a new one # View a Project Review one project's environments, teams, roles, and API tokens. ## Goal [#goal] Check that the project has the environments and access you expect. ## What you need [#what-you-need] * The correct organization selected * Permission to view the project * The project name or list entry you want to open ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Show details for project `acme-platform`" * "List environments in project `northwind`" * "What teams and roles are configured for `design-studio`?" ## What you see [#what-you-see] * **Environments:** separate infrastructure setups inside the project (dev, staging, production) * **Teams:** who can work in this project * **Roles:** access rules for project members * **API tokens:** tokens for this project when you use the API or MCP ## Verify [#verify] * You opened the project you intended * Environments, teams, and roles match what you expect * API tokens are listed when you need them for automation ## Common issues [#common-issues] * You cannot view project details: confirm your role in the selected organization * An environment is missing: [add an environment](/docs/environments/add-environment) * API tokens are missing: create tokens for this project when you need API or MCP access ## What to do next [#what-to-do-next] * [Add an environment](/docs/environments/add-environment) when the project needs another infrastructure setup * [Add an application](/docs/applications/add-application) inside an environment * [Edit the project](/docs/projects/edit-project) when the name or settings need to change # Add a Role Create a permission set you can reuse across multiple team memberships. ## Goal [#goal] Define what teams can do before granting access. ## Who should use this [#who-should-use-this] * Organization admins creating reusable access sets * Team leads setting access rules ## You need [#you-need] * Permission to create roles in the organization ## Steps [#steps] 1. Open the organization role settings 2. Open `Roles` 3. Click `ADD ROLE` 4. Enter a name and optional description 5. Select the permissions you want the role to allow 6. Click `CONFIRM` ## Expected result [#expected-result] * The new role is saved in the organization * You can attach it when creating team memberships ## Common issues [#common-issues] * Save fails: verify permission to manage roles * Missing permission options: ensure you have role configuration access ## Next [#next] * Attach the role through [Team Memberships](/docs/environments/team-memberships/add-team-membership) # Roles Roles are permission sets for role-based access control (RBAC).\ They define what a team can do when that role is applied at the organization, project, or environment level. ## About [#about] * Roles are permission sets that control team actions across Devopness * A role can apply to an organization, a project, or an environment * Teams use roles to grant access with the right level of permission ## Who should use this [#who-should-use-this] * Organization owners who standardize access policy * Project and environment admins assigning team access ## Why this exists [#why-this-exists] * Roles reduce repeated permission setup for many teams * Roles make it easier to review security behavior during audits ## Relationship to other concepts [#relationship-to-other-concepts] * Teams hold people * Roles hold allowed actions * Team Memberships attach a role to a team in an environment ## Start here [#start-here] * Create roles in [Add a Role](/docs/roles/add-role) * Attach a role when creating [Team Memberships](/docs/environments/team-memberships/add-team-membership) # List Roles Review all roles defined in your organization. ## Goal [#goal] Find the right role before granting a team access in environment settings. ## Who should use this [#who-should-use-this] * Organization admins checking available permission sets * Environment admins assigning team access ## You need [#you-need] * Permission to view organization roles ## Steps [#steps] 1. Open the organization where roles are managed 2. Open `Roles` 3. Open the role list 4. Select a role to inspect details ## Expected result [#expected-result] * You can confirm all available roles and what they allow * You can open one role to verify permissions before assigning it ## Common issues [#common-issues] * List is empty: confirm roles exist in this organization * You cannot open details: check role read permission ## Next [#next] * Inspect a role in [Check a Role's Permissions](/docs/roles/view-role) # Check a Role's Permissions Inspect what a role can do before assigning it to a team. ## Goal [#goal] Understand the exact permissions a role grants in an environment. ## Who should use this [#who-should-use-this] * Team owners reviewing security impact * Environment admins choosing a safe access level ## You need [#you-need] * Permission to view role definitions ## Steps [#steps] 1. Open the organization and go to `Roles` 2. Select the role you want to verify 3. Review each permission group and action in the role details 4. Confirm it matches the access you expect before using it in memberships ## Expected result [#expected-result] * You can decide whether the role is safe for the target environment * You can avoid giving teams more access than needed ## Common issues [#common-issues] * You cannot see permissions: confirm organization-level read access * Permission list is unclear: reopen from list to view the latest definition ## Next [#next] * Update access by assigning roles through [Team Memberships](/docs/environments/team-memberships) # Security This section contains all documentation related to the product's security topics. # Reporting a Security Vulnerability Report a security vulnerability providing the necessary information to our development team. ## Where to report a security vulnerability [#where-to-report-a-security-vulnerability] To report security-related bugs, use Devopness' open source repo [security](https://github.com/devopness/devopness/security/advisories) section and our team will analyze the report and circle back once the validity of the report has been assessed. **DO NOT** submit a ticket or post to any public groups. ## How to write a good vulnerability report [#how-to-write-a-good-vulnerability-report] 1. Give a short summary of the problem. Focus on making the vulnerability's impact and severity as clear as possible. 2. Tell which Devopness module is affected (Devopness API, Devopness website, Devopness web app, API Documentation, Devopness SDK). 1. Tell which versions are affected (in case of Devopness SDK). 3. Then, give all details gathered about the vulnerability. If you are able to point to the part of the source code responsible for the vulnerability, you will be helping the maintainers tackle the problematic code more quickly. 4. Lay out the steps of PoC (Proof of Concept). Aim to make the steps as complete as possible. Also, include specific configuration details, if relevant. 5. Explain the vulnerability's impact. What kind of vulnerability is it? Who is impacted by it? # Add a Server to Amazon Web Services (AWS) Devopness allows you to provision a server on AWS using Elastic Compute Cloud (EC2) and manage it through Devopness. > If you don't have an AWS credential, please follow the guide [Add aws credential](/credentials/add-aws-credential) 1. On Devopness, navigate to a project then select an environment 2. If there's no other server in the selected environment, just click `ADD SERVER` 3. If a list of resource cards is displayed, find the `Servers` card and click View on it 4. On the upper-right corner of the list click `ADD SERVER` 5. Choose `Amazon Web Services` as cloud provider 6. Select a `Credential` > If no credential is listed or you want to use a different one, click `Create a new credential` and follow the guide [Add a Credential](/credentials/add-credential) 7. Follow the prompts to complete the configuration of the new `Server` 8. Review server information and settings. If everything is correct, click `CONFIRM` > Use the `PREVIOUS` button if you need to modify any server details 9. Wait for the `server:provision` action to be completed 10. After the server is successfully provisioned it will be visible on `AWS` console 11. If you want to access the server on `AWS` console: * Access [AWS console](https://console.aws.amazon.com/) * On the Search box, enter “EC2” and select it from search results * In the upper-right corner select the region on which server was provisioned * Click `Instances` * An `EC2` instance will be listed, with the name of the new `Server` you provisioned on Devopness # Add a Server to Microsoft Azure Devopness allows you to provision a server on Azure Resource Manager (RM) and manage it through Devopness. > If you don't have an Azure credential, please follow the guide [Add Microsoft Azure Credential](/credentials/add-azure-credential) > Microsoft Azure requires that you create your own custom network and subnet to provision a server, if you don't have one, please follow the guide [Add a Network](/networks/add-network) 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click `View` in the `Servers` card to see a list of existing `Servers` 4. On the upper-right corner of the list click `ADD SERVER` 5. Choose `Microsoft Azure` as cloud provider 6. Select a `Credential` > If no credential is listed or you want to use a different one, click `Create a new Credential` and follow the guide [Add a Credential](/credentials/add-credential) 7. Follow the prompts to complete the configuration of the new `Server` 8. Review server information and settings. If everything is correct, click `CONFIRM` > Use the `PREVIOUS` button if you need to modify any server details 9. Wait for the `server:provision` action to be completed 10. After the server is successfully provisioned it will be visible on `Azure` portal 11. If you want to access the server on `Azure` portal: * Access [Azure Portal](https://portal.azure.com/) * In the search bar, type and select `Virtual machines` * An `Virtual Machine` instance will be listed, with the name of the new `Server` you provisioned on Devopness # Add a Server to DigitalOcean Devopness allows you to provision a server on DigitalOcean using Droplets and manage it through Devopness. > If you don't have an DigitalOcean credential, please follow the guide [Add DigitalOcean Credential](/credentials/add-digitalocean-credential) 1. On Devopness, navigate to a project then select an environment 2. If there's no other server in the selected environment, just click `ADD SERVER` 3. If a list of resource cards is displayed, find the `Servers` card and click View on it 4. On the upper-right corner of the list click `ADD SERVER` 5. Choose `DigitalOcean` as cloud provider 6. Select a `Credential` > If no credential is listed or you want to use a different one, click `Create a new credential` and follow the guide [Add a Credential](/credentials/add-credential) 7. Follow the prompts to complete the configuration of the new `Server` 8. Review server information and settings. If everything is correct, click `CONFIRM` > Use the `PREVIOUS` button if you need to modify any server details 9. Wait for the `server:provision` action to be completed 10. After the server is successfully provisioned it will be visible on `DigitalOcean` console 11. If you want to access the server on `DigitalOcean` console: * Log in to [DigitalOcean Control Panel](https://cloud.digitalocean.com/) * Find the droplets section * A `droplet` instance will be listed, with the name of the new `Server` you provisioned on Devopness # Add an Existing Server If you have servers provisioned outside of your desired environment on Devopness, you can still connect them to your Devopness account and take the most of the Devopness infrastructure management features. 1. On Devopness, navigate to a project then select an environment 2. If there's no other server in the selected environment, just click `Add Server` 3. If a list of resource cards is displayed, find the `Servers` card 4. Click `View` in the `Servers` card to see a list of existing `Servers` 5. On the upper-right corner of the list click `ADD SERVER` 6. On the `Cloud Provider` drop-down menu choose `VPS/Self Hosted` 7. Provide the `Public IP address` of your existing server 8. Enter the `SSH Port` to be used to connect to the server We do not recommend connecting servers that are already being used in production. Server's existing configuration will be lost and replaced by Devopness during the server setup process 9. Click `NEXT` 10. Follow the prompts to complete the configuration of the new `Server` 11. Click `CONFIRM` * If you see a message saying `Error establishing a SSH connection to server`, please verify if the IP address and SSH port used are correct and if external SSH connections are allowed on this server 12. After the `Server` is added you will be redirected to the `Connect` page 13. Find the `Command to connect` field and click `Copy to clipboard` 14. Log into your server as the `root` user 15. Paste the command that has been copied to the clipboard and run it 16. A message will be displayed in the terminal window when the server connect command is successfully completed 17. On Devopness, once the server is displayed as `Connected`, it's been added to the selected environment # Add a Server to Google Cloud Platform (GCP) Devopness allows you to provision a server on GCP using Google Compute Engine (GCE) and manage it through Devopness. > If you don't have a GCP credential, please follow the guide [Add Google Cloud Platform (GCP) Credential](/credentials/add-gcp-credential) 1. On Devopness, navigate to a project then select an environment 2. If there's no other server in the selected environment, just click `ADD SERVER` 3. If a list of resource cards is displayed, find the `Servers` card and click View on it 4. On the upper-right corner of the list click `ADD SERVER` 5. Choose `Google Cloud Platform` as cloud provider 6. Select a `Credential` > If no credential is listed or you want to use a different one, click `Create a new credential` and follow the guide [Add a Credential](/credentials/add-credential) 7. Follow the prompts to complete the configuration of the new `Server` 8. Review server information and settings. If everything is correct, click `CONFIRM` > Use the `PREVIOUS` button if you need to modify any server details 9. Wait for the `server:provision` action to be completed 10. After the server is successfully provisioned it will be visible on the GCP console 11. If you want to access the server on the GCP console: * Access [GCP Console](https://console.cloud.google.com/) * On the Search box, enter “Compute Engine” and select it from search results * A `GCE` instance will be listed, with the name of the new `Server` you provisioned on Devopness # Add a Server Devopness allows you to provision servers on multiple cloud providers or connect to existing servers. Choose one of the related topics below to get specific instructions for the cloud provider on which you want to add a new server. # Check Server Provision Logs Sometimes you may encounter problems while provisioning your servers. Check your server' actions logs to evaluate what happened. 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card 4. On the upper-right corner, click `ACTIONS` to see a list of actions for all `Servers` of the current environment 5. In the list of actions, locate the action you want to inspect and click its Action ID (e.g., #51899) in the Actions column to open the action details page > There are 3 actions related to the server provision process: `Provision`, `Provision-check` and `Add`; > each action can have one of the following status: `Queued`, `Pending`, `In progress`, `Completed` or `Failed`. 6. In the action details view, you'll see a list of action steps. For each step, click the `LOGS` button to view its detailed logs 7. A text area will be displayed containing the output log of the action step execution # Delete a Server provisioned by Devopness Learn how to delete a server provisioned by Devopness on a cloud provider This action will delete all server data on the cloud provider 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card, to see a list of existing `Servers` 4. In the list of servers, find the server you want to delete and click the `NAME` of the server 5. On the upper-right corner of the server details view, click `REMOVE` 6. Follow the prompts then click `REMOVE` 7. Wait for the `server:remove` action to be completed > If this action fails, maybe your server status is different from "stopped", if this is the case follow the guide [Stop a Server](/servers/stop-server) 8. Follow the guide [Get a Server’s Status](/servers/get-server-status) > The server status will be "deleted" # Find your Server IP Address Having the IP address of a server is useful when performing operations that require network connections to the server, such as log in to your server via SSH to run commands in a terminal or configuring a DNS record so your application can be accessed using a domain name. 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card to see a list of existing `Servers` 4. In the list of servers, find the server you want to connect > The ip address is a number separated by dots, e.g: 41.234.56.78 5. Copy the server' IP Address # Get a Server’s Status Sometimes you might want to check if a server is currently running. Get the server status to check if a server is currently running, stopped or deleted. 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card to see a list of existing `Servers` 4. In the list of servers, find the server you want to inspect and click the `NAME` of the server 5. On the upper-right corner of the server details view click `ACTIONS` 6. Use the drop-down menu to choose `Status` 7. Wait for the `server:get-status` action to be completed 8. Check the action logs to see the server's current status # Servers Devopness allows you to provision servers on multiple cloud providers or connect to existing servers. In this section you will learn how to create, inspect, connect and manage servers. # List Servers View the list of servers in your environment 1. On the Devopsness home page, navigate to a project and select your desired environment. 2. If there are no servers, create one. Refer to the `Add a Server` documentation page. 3. On the `Environments` page, click on the **Servers** card or the **VIEW ALL** option at the bottom of the card. 4. Here, on the `Servers` page, you can find the list of servers with details of the provider, region, IP address, port and status. 5. Click on a particular server to view its details. # Remove a Self Hosted Server Learn how to remove a self hosted server Removing a self hosted server will not delete its data from the host 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card, to see a list of existing `Servers` 4. In the list of servers, find the server you want to remove and click the `NAME` of the server 5. On the upper-right corner of the server details view, click `REMOVE` 6. Follow the prompts then click `REMOVE SERVER` 7. Wait for the `server:remove` action to be completed > If this action fails, maybe your server status is different from "stopped", if this is the case follow the guide [Stop a Server](/servers/stop-server) 8. Follow the guide [Get a Server’s Status](/servers/get-server-status) > The server status will be "deleted" # Remove a Server Learn how to remove a server when it's no longer needed. As Devopness allows you to provision servers on multiple cloud providers, or even connect existing servers, the steps to remove a server will vary per cloud provider. Choose one of the related topics below to get specific instructions for the cloud provider from which you want to remove a server. # Restart a Server Sometimes running many concurrent pipelines may slow down your servers. Restart your server to force all running tasks to end and start the server again in the same action. 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card to see a list of existing `Servers` 4. In the list of servers, find the server you want to restart and click the `NAME` of the server 5. On the upper-right corner of the server details view click `ACTIONS` 6. Use the drop-down menu to choose `Restart` 7. Wait for the `server:restart` action to be completed 8. Follow the guide [Get a Server’s Status](/servers/get-server-status) > The server status will be "running" # Rotate the server's machine credential key The server's machine credential is the key used by Devopness to connect to your server. 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card to see a list of existing `Servers` 4. In the list of servers, find the server for which you want to rotate the machine credential key and click the `NAME` of the server 5. On the upper-right corner of the server details view, click `ACTIONS` 6. Use the drop-down menu to choose `Rotate Key` 7. Wait for the `server:rotate-key` action to be completed # Connect to your servers using SSH Sometimes you and your team members need to connect to your servers to run commands from the terminal. Connect via SSH to ensure your servers only executes commands by authorized SSH keys. 1. On Devopness, copy the IP Address of the server you want to connect > Follow the [Find your Server IP Address](/servers/find-server-ip-address) guide 2. On your local machine, in a terminal window, use the `ssh` command to connect to the server ```bash ssh devopness@ ``` > This should give you shell access to your remote server hosted at the IP address, logged in as user `devopness` > If you receive a `Connection refused` error, please follow the [Add an SSH key](/ssh-keys/add-ssh-key) guide 3. Test your SSH connection running simple commands on your server, e.g: `whoami` or `ls` 4. When you are finished with your remote server terminal usage, run the `exit` command to close the SSH connection. # Start a Server A stopped server can be started to enable creating and running server resources such as applications and cron jobs. Start a stopped server to enable your users to connect to its linked resources. 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card to see a list of existing `Servers` 4. In the list of servers, find the server you want to start and click the `NAME` of the server 5. On the upper-right corner of the server details view click `ACTIONS` 6. Use the drop-down menu to choose `Start` 7. Wait for the `server:start` action to be completed 8. Follow the guide [Get a Server’s Status](/servers/get-server-status) > The server status will be "running" # Stop a Server Sometimes you may want to interrupt a server to stop a long running task. Stop a server to force any running tasks to end. Any applications or daemons on this server will stop working as a consequence of the server being stopped. Your server's public IP address will be updated the next time the server is started, unless you have a static IP address set configured for the selected instance on your cloud provider. That means that if your server does not have a static IP address associated to it, the next time this server is started all domains that point to this server's old IP address will need to be updated to point to the server's new IP address. 1. On Devopness, navigate to a project then select an environment 2. Find the `Servers` card 3. Click the `View` in the `Servers` card to see a list of existing `Servers` 4. In the list of servers, find the server you want to stop and click the `NAME` of the server 5. On the upper-right corner of the server details view click `ACTIONS` 6. Use the drop-down menu to choose `Stop` 7. Wait for the `server:stop` action to be completed 8. Follow the guide [Get a Server’s Status](/servers/get-server-status) > The server status will be "stopped" # View a Server In this section you will learn how to run server actions. # Add a service Often applications rely on background processes, such as web servers or databases, to deliver results. Add a Service to manage linux services, such as web servers or databases to all servers and applications that depend on them. 1. On Devopness, navigate to a project then select an environment 2. Find the `Services` card 3. Click `View` in the `Services` card to see a list of existing `Services` 4. On the upper-right corner of the list click `ADD SERVICE` 5. Follow the prompts then click `CONFIRM` 6. In the `Service` details view, the recently created `Service` details can be seen # Services Many applications depend on background services, like web servers and databases, to function effectively. Devopness simplifies the management of these essential services by providing a centralized platform, allowing you to configure, monitor, and maintain all that in one place. # Remove a Service Remove a Service when it is no longer needed. 1. On Devopness, navigate to a project then select an environment 2. Find the `Services` card 3. Click `View` in the `Services` card to see a list of existing `Services` 4. In the list of services, find the service you want to remove click the `NAME` of the service 5. On the upper-right corner of the service details view, click `REMOVE` 6. Follow the prompts then click `REMOVE SERVICE` 7. In the list of services, the recently removed `Service` will be gone # Add an SSH key Sometimes you and your team members need to connect to your servers to run commands from the terminal. Add SSH keys to environment servers to ensure secure server access by only the authorized SSH keys. 1. On Devopness, navigate to a project then select an environment 2. Find the `SSH Keys` card 3. Click `View` in the `SSH Keys` card to see a list of existing `SSH Keys` 4. On the upper-right corner of the list click `ADD SSH KEY` 5. Provide a name to the `SSH Key` being added. For example, "Company Laptop" 6. Paste in the public key * If you want to create a new key, see [Create an SSH key pair](/ssh-keys/create-ssh-key-pair) for instruction on how to create a public key 7. Click `NEXT` 8. Follow the prompts to complete the configuration of the new `SSH Key` 9. Click `CONFIRM` # Create an SSH key pair Sometimes you may need to connect to your servers using an SSH client to run terminal commands on your remote server. An SSH public key is used for secure authentication when you use an SSH client to connect to a server managed by Devopness. When you connect, you must provide the private key that matches the public key added to the remote server. Create an SSH private/public key pair to securely authenticate your server access on the new device. Several tools exist to generate SSH public/private key pairs. The following steps show how to generate an SSH key pair on UNIX and UNIX-like platforms. 1. On your local machine, in a terminal window, run the command below, replacing `` with a valid email address ```bash ssh-keygen -t rsa -b 4096 -C "" ``` > This creates a new SSH key, using the provided email as a label. 2. Follow the prompts to complete the creation of the new SSH Key pair > There should be 2 new files inside `$USER/.ssh` directory, `id_rsa` (private key) and `id_rsa.pub` (public key) 3. To add the public key (`id_rsa.pub`) to Devopness, see [Add an SSH key](/ssh-keys/add-ssh-key) # Deploy SSH Key Deploy your SSH Keys to each of the servers you want to give access to using those keys. 1. On Devopness, navigate to a project then select an environment 2. Find the `SSH Keys` card 3. Click `View` in the `SSH Keys` card to see a list of existing `SSH Keys` 4. In the list of SSH keys, find the SSH key you want to deploy and click the `NAME` of the SSH key 5. On the upper-right corner of the SSH key details view, click `DEPLOY` 6. Choose a deploy pipeline to be run, then click `Next` 7. Review deploy information, then click `DEPLOY` 8. Wait for the `ssh-key:deploy` action to be completed # SSH keys In this section you will learn how to create an SSH key pair, add SSH keys to an infrastructure environment, authorize the added keys to allow users to SSH into one or multiple servers and how to remove access from users that should no longer be able to login into servers to which they used to have access. # Link an SSH Key to a Server Link an SSH Key to a server to select which SSH keys a server can have deployed. 1. On Devopness, navigate to a project then select an environment 2. Find the `SSH Keys` card 3. Click `View` in the `SSH Keys` card to see a list of existing `SSH Keys` 4. In the list of SSH keys, find the SSH key you want to link to a server and click the `NAME` of the SSH key 5. Click the `Servers` tab 6. On the upper-right corner of the servers tab click `LINK SERVER` 7. Follow the prompts then click `CONFIRM` 8. In the `Servers` list, the recently linked server can be seen # List SSH Keys At times, you or your team members may need to connect to your servers to execute commands directly from the terminal. To ensure secure access, you can add SSH keys to your environment servers, allowing connections only from authorized keys. ## How to List SSH Keys [#how-to-list-ssh-keys] 1. In the Devopness dashboard, navigate to your desired project, then select the relevant environment. 2. Locate the `SSH Keys` card on the environment page. 3. Click the `View` button on the `SSH Keys` card to display the list of SSH keys currently added to the environment. 4. If no keys are listed, follow the steps in the [Create SSH Key Pair](../ssh-keys/create-ssh-key-pair) and [Add SSH Key](../ssh-keys/add-ssh-key) guides to add your first key. # Remove an SSH Key Learn how to remove an SSH Key when it's no longer needed 1. On Devopness, navigate to a project then select an environment 2. Find the `SSH Keys` card 3. Click the `View` in the `SSH Keys` card, to see a list of existing `SSH Keys` 4. In the list of keys, find the key you want to remove and click the `NAME` of the key 5. On the upper-right corner of the key details view, click `REMOVE` 6. Follow the prompts then click `REMOVE SSH KEY` 7. In the list of keys, the recently removed `SSH Key` will be gone # View SSH Key After adding SSH keys to your environment, you may want to review the details of a specific key, such as its label, fingerprint, or creation date. This helps in managing and auditing server access effectively. ## How to View Details of an SSH Key [#how-to-view-details-of-an-ssh-key] 1. In the Devopness dashboard, navigate to your project, then select the environment where the SSH key was added. 2. Locate the `SSH Keys` card and click `View` to open the list of SSH keys associated with the environment. 3. From the list, click on the SSH key you want to inspect. 4. The `SSH key` details page will display important information such as: * **Name**: A user-friendly name for the key. * **Fingerprint**: A unique identifier for the key. * **Created At**: When the key was added to the environment. Use this view to verify key details or to confirm which keys have access to your servers. # Add an SSL Certificate Add an SSL Certificate to secure communication between clients and servers, ensuring data confidentiality and integrity. 1. On Devopness, navigate to a project then select an environment 2. Find the `SSL Certificates` card 3. Click `View` in the `SSL Certificates` card to see a list of existing `SSL Certificates` 4. On the upper-right corner of the list, click `ADD SSL CERTIFICATE` 5. On the `Virtual Host` dropdown menu, choose a virtual host * The name of your SSL certificate will be the name of the chosen virtual host 6. Follow the prompts then click `CONFIRM` 7. In the `SSL Certificates` list, the recently created `SSL Certificate` can be seen # SSL Certificates Devopness allows you to manage SSL certificates to secure your applications and websites. # List SSL Certificates View and manage all SSL certificates associated with your project. 1. On Devopness, navigate to a project then select an environment 2. Find the `SSL Certificates` card 3. Click `View` in the `SSL Certificates` card to see a list of existing `SSL Certificates` 4. The list displays all SSL certificates associated with the selected environment 5. You can filter certificates by status, search by name or domain, and sort by different columns 6. Click on any certificate to view its detailed information # View SSL Certificate View detailed information about a specific SSL certificate and manage its lifecycle. 1. On Devopness, navigate to a project then select an environment 2. Find the `SSL Certificates` card 3. Click `View` in the `SSL Certificates` card to see a list of existing `SSL Certificates` 4. Click on the specific SSL certificate you want to view # Add a Subnet Add a subnet to your network when you need to define custom network topology within a network. 1. On Devopness, navigate to a project then select an environment 2. Find the `Networks` card 3. Click `View` in the `Networks` card, to see a list of existing `Networks` 4. In the list of networks find the network where you want to add a subnet and click the `NAME` of the network 5. On the upper-right corner of network details view, click the `Subnets` tab 6. On the upper-right corner of subnets tab click `MANAGE` 7. Follow the prompts 8. Provide a name to the Subnet being added. Example: "Public Subnet A", "Private Subnet B" 9. Select a `Type` and click `NEXT` 10. Provide a CIDR block to the Subnet being added. Example: "10.108.0.0/20" 11. Click `CONFIRM` * After the Subnet is created an action will be automatically started to provision the Subnet on the chosen cloud provider # Subnets Learn how to provision and manage cloud subnetworks # Remove a Subnet Learn how to remove a subnet when it's no longer needed 1. On Devopness, navigate to a project then select an environment 2. Find the `Networks` card 3. Click `View` in the `Networks` card, to see a list of existing `Networks` 4. In the list of networks, find the network with the subnet you want to remove and click the `NAME` of the network 5. On the upper-right corner of network details view, click `SUBNETS`, to see a list of existing `Subnets` 6. In the list of subnets, find the subnet you want to remove and click the `NAME` of the subnet 7. On the upper-right corner of the subnet details view, click `REMOVE` 8. Follow the prompts then click `REMOVE SUBNET` 9. In the `Subnets` list, the recently removed `Subnet` will be gone # Add a Team Create a new team inside an organization so many people can share access settings. ## Goal [#goal] Set up a team to reuse the same role setup for project and environment access. ## Who should use this [#who-should-use-this] * Organization admins creating reusable access setup * Project owners assigning teams to environments and projects ## You need [#you-need] * Permission to create teams in the organization ## Steps [#steps] 1. Open the organization that owns the new team 2. Open `Teams` 3. Click `ADD TEAM` 4. Enter a clear team name 5. Click `CONFIRM` ## Expected result [#expected-result] * The new team appears in the team list * You can invite people to it and later assign it to environments ## Common issues [#common-issues] * You cannot save: confirm team creation permission * Name is rejected: choose a unique and readable team name ## Next [#next] * Add members with [Invite Team Member](/docs/teams/invitations/add-invitation) # Teams Teams are groups of people in an organization so multiple people can share the same access setup in one place. ## About [#about] * Teams are created at organization level, not inside one project * Members get access from the team role that is set on each environment * Teams keep access behavior the same as people are added or removed ## Who this is for [#who-this-is-for] * Organization owners who want one place to manage people access * Team leads sharing work on environments and projects * Project admins adding or removing many people at once ## Why this exists [#why-this-exists] * It helps you add people to a team once instead of editing each person * It keeps access consistent when people join or leave the team ## Relationship to other concepts [#relationship-to-other-concepts] * Organization owns teams and roles * Project admins can link teams to project and environment workflows * Environment admins can use Team Memberships to grant a team role in an environment ## Start here [#start-here] * Use [Add a Team](/docs/teams/add-team) to create the group * Open the team in [List Teams](/docs/teams/list-teams) to confirm members * Link teams to environments from [Team Memberships](/docs/environments/team-memberships) ## Next [#next] * Review [Roles](/docs/roles) before assigning environment access # List Teams View all teams in an organization and confirm who is available for access. ## Goal [#goal] Use this page to verify team structure before you use them for access. ## Who should use this [#who-should-use-this] * Organization owners planning role-based access * Project admins checking team availability * Environment admins setting up environment grants ## You need [#you-need] * Access to the target organization * Permission to view teams ## Steps [#steps] 1. Open the target organization 2. Open `Teams` 3. Open the full team list 4. Confirm each team name and status ## Expected result [#expected-result] * You can see all teams in the organization * You can open a team to assign members or invitations ## Common issues [#common-issues] * No teams appear: verify you are in the right organization * Missing actions: confirm team read permissions ## Next [#next] * Open a team in [View a Team](/docs/teams/view-team) to manage its members and settings # View a Team Review one team and understand who is attached before changing membership or access. ## Goal [#goal] Check team state before you invite members or reuse the team in environments. ## Who should use this [#who-should-use-this] * Organization owners validating team health * Project admins connecting teams to project workflows ## You need [#you-need] * Permission to view team details in the organization ## Steps [#steps] 1. Open the organization that owns the team 2. Open `Teams` 3. Select the team you want to review 4. Open related sections for members or invitations ## Expected result [#expected-result] * You can confirm current members and invite activity * You can open invites or team access actions from there ## Common issues [#common-issues] * Team details are hidden: check your organization role * Member list looks stale: refresh the team view ## Next [#next] * Invite people with [Invite Team Member](/docs/teams/invitations/add-invitation) # Find your Devopness Activity Summary Curious about how much have Devopness impacted your infraestructure management related work? Why not check how much have we accomplished together using your activity summary information. 1. Obtain a `Personal Access Token` by following the instructions in [Personal Access Tokens](/api-tokens/personal-access-tokens) 2. On your local machine, in a terminal window, submit a request to Devopness API endpoint `GET /users/me`, replacing `` with the value of your `Personal Access Token` ```bash curl --request GET \ --url https://api.devopness.com/users/me \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' ``` 1. From the previous command response, copy the field `id` 2. On your local machine, in a terminal window, submit a request to Devopness API endpoint `GET /users//activity`, replacing `` and `` ```bash curl --request GET \ --url https://api.devopness.com/users//activity \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' ``` # Users In this section you will learn how to manage your user profile settings, subscriptions, and activity. ## Start here [#start-here] * Find your activity summary in [Find your Devopness Activity Summary](/docs/users/find-your-activity-summary) * Manage invites sent to you in [Received Invitations](/docs/users/teams/invitations/list-invitations) * Manage billing and plans in [Billing and Plans](/users/subscriptions) # Add a Variable Variables are key/value pairs accessible by Pipeline Step commands. Use environment Variables to store configuration data used by commands in your Pipeline steps (such as compiler flags, environment specific configuration, credentials and secrets). If a resource requires multiple Variables to be written to a custom file (e.g. an Application `.env` file), we recommend storing them using 'Configuration Files' instead of multiple variables. 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card to see a list of existing `Applications` 4. In the list of applications, find the application to which you want to add a variable and click the `NAME` of the application 5. Click the `VARIABLES` tab 6. On the right corner of the variables tab click `ADD VARIABLE` 7. Follow the instructions in the add variable step form then click `CONFIRM` > A new deployment is required for your changes to take effect. * Follow the guide [Deploy Application](/applications/deploy-application) # Edit a Variable You can edit variables directly on Devopness every time you need to update the value of an existing variable used by your deployment pipelines. 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card to see a list of existing `Applications` 4. In the list of applications, find the application with the variable you want to edit and click the `NAME` of the application 5. Click the `VARIABLES` tab 6. In the list of variables, find the variable you want to edit and click the `NAME` of the variable 7. On the upper-right corner of the variable details view, click `EDIT` 8. Follow the instructions in the variable edit form then click `CONFIRM` > A new deployment is required for your changes to take effect. * Follow the guide [Deploy Application](/applications/deploy-application) # Variables Variables are used to store configuration settings that are used by application and infrastructure resources. For example, a `PORT` variable can define the port on which the application listens for incoming requests. Using Devopness you can easily manage and organize multiple variables on your environment resources defining custom variables to be set during a deploy, without the need of hard-coding them directly into your application code and without the need of SSH into your server every time an environment variable needs to be updated. # Remove a Variable Learn how to remove a variable when it's no longer needed. 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card, to see a list of existing `Applications` 4. In the list of applications, find the application with the variable you want to remove and click the `NAME` of the application 5. Click the `VARIABLES` tab 6. In the list of variables, find the variable you want to remove and click `REMOVE` 7. Follow the prompts then click `REMOVE VARIABLE` 8. In the list of variables, the recently removed `Variable` will be gone > A new deployment is required for your changes to take effect. * Follow the guide [Deploy Application](/applications/deploy-application) # Add a Virtual host Add a Virtual Host to make an application accessible on the internet, by server IP address or a domain name 1. On Devopness, navigate to a project then select an environment 2. Find the `Virtual hosts` card 3. Click `View` in the `Virtual hosts` card to see a list of existing `Virtual hosts` 4. On the upper-right corner of the list click `ADD VIRTUAL HOST` 5. Follow the prompts then click `CONFIRM` 6. In the `Virtual hosts` list, the recently created virtual host can be seen * A new deployment is required for your changes to take effect * Follow the guide [Run a Pipeline](/pipelines/run-pipeline) Tips: * Add one virtual host per domain you want to use (for example `www.my-product.ai`, `demo.my-product.ai`, `api.my-product.ai`). * You can add multiple virtual hosts for the same application when you need multiple domains. For virtual hosts of type `Server IP address` ("ip-based virtual host"), please make sure: ``` - the virtual host *hostname* is the IP address of the server to which the virtual host was successfully deployed ``` For virtual hosts of type `Domain name` ("name-based virtual host") please make sure: ``` - a DNS record with the same name of the "name-based virtual host" exists - the DNS record is pointing to the IP address of the server to which the virtual host was successfully deployed ``` Follow the steps below to configure a DNS record pointing to your server: 1. Copy the IP Address of the server to which the virtual host has been deployed * Follow the guide [Find your Server IP Address](/servers/find-server-ip-address) 2. Access your DNS service management panel * If you don't have your own domains configured with a DNS service, you can use free services such as [FreeDNS](https://freedns.afraid.org/) or hire paid managed DNS services such as [AWS Route53](https://aws.amazon.com/route53/), [Cloudflare DNS](https://www.cloudflare.com/dns/), or any [notable managed DNS service provider](https://en.wikipedia.org/wiki/List_of_managed_DNS_providers) that suits your needs 3. Configure a DNS record for your virtual host domain * Follow the specific instructions on your chosen DNS service documentation 4. Verify your DNS record is pointing to your Devopness managed server * This can be verified using a DNS propagation checker such as [whatsmydns](https://www.whatsmydns.net/) or [DNS Checker](https://dnschecker.org/) in order to secure all network connections with your virtual host, and ensure all data submitted to your domain name is encrypted over the HTTPS protocol, follow the guide on how to [Add an SSL Certificate](/ssl-certificates/add-ssl-certificate) # Edit a Virtual host Edit a Virtual Host to change how an application is accessible on the internet , by server IP address or a domain name 1. On Devopness, navigate to a project then select an environment 2. Find the `Virtual hosts` card 3. Click `View` in the `Virtual hosts` card to see a list of existing `Virtual hosts` 4. In the list of virtual hosts, find the virtual host you want to edit and click the `NAME` of the virtual host 5. On the upper right corner of the application details view, click `EDIT` 6. Follow the prompts then click `CONFIRM` * A new deployment is required for your changes to take effect * Follow the guide [Run a Pipeline](/pipelines/run-pipeline) # Virtual Hosts Learn how to configure Virtual Hosts to have one or more applications accessible on the internet, by server IP address or a domain name ## When to add a virtual host [#when-to-add-a-virtual-host] Add a virtual host for each domain you want to route to an application (for example `app.my-product.com` or `demo.my-product.com`). You can add multiple virtual hosts per environment and per application. # List Virtual Hosts View and manage all virtual hosts associated with your project. 1. On Devopness, navigate to a project then select an environment 2. Find the `Virtual hosts` card 3. Click `View` in the `Virtual hosts` card to see a list of existing `Virtual hosts` # View Virtual Host View detailed information about a specific virtual host and manage its configuration. 1. On Devopness, navigate to a project then select an environment 2. Find the `Virtual hosts` card 3. Click `View` in the `Virtual hosts` card to see a list of existing `Virtual hosts` 4. Click on the specific virtual host you want to view # Create an Incoming Webhook Incoming Webhooks are a simple way to integrate external services with your Devopness environments, using a unique URL through which a JSON payload can be sent to run a pipeline with custom input data. Some use cases of external services events include "deploy applications automatically based on GitHub/GitLab/Bitbucket repository updates", "provision and scale infrastructure resources when you payment gateway confirms that a custom subscription has been processed", and many more use cases that can benefit from webhooks integration. Learn how to create an incoming webhook to run pipelines programmatically when events happen on external services. At Devopness we treat our `API-as-a-Product`, meaning that every feature in our product is first designed with the API usage in mind, resulting in an API that is easy to use, well documented and actively maintained and supported. This `API-first` development approach makes it possible that every piece of functionality available to users of our web app can also be automated and integrated with external systems. Devopness webhooks are a highly performant way to allow applications to push data from external events to trigger pipelines on your infrastructure environments, increasing productivity and reliability while working on cloud applications and infrastructure management workflows. Webhooks, for now, are an API only feature; so this post will guide you through the usage of our API to help you create a webhook. ## Step 1: Get the data needed for creating a webhook [#step-1-get-the-data-needed-for-creating-a-webhook] 1. Make sure you have API access by following the instructions in [Devopness API Reference](/api) 2. Take note of the ID (``) of the pipeline which you want to run programatically > Follow the [Deploy Application using an Incoming Hook](/applications/deploy-application-using-incoming-hook) guide for detailed instructions 3. On your local machine, in a terminal window, submit a request to Devopness API endpoint `POST /users/login` using your Devopness account email and password ```bash curl --request POST \ --url https://api.devopness.com/users/login \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{ "email": "", "password": "" }' ``` 4. From the previous command response, copy the field `access_token` ## Step 2: Create the webhook [#step-2-create-the-webhook] 1. On your local machine, in a terminal window, submit a request to Devopness API endpoint `POST /pipelines/:id/hooks/incoming`, replacing ``. ```bash curl --request POST \ --url https://api.devopness.com/pipelines//hooks/incoming \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "name": "Deploy `main` branch", "requires_secret": true, "secret_algorithm": "sha256", "secret_header_name": "x-hub-signature-256", "action_type": "deploy", "settings": { "variables": [ { "name": "source_type", "type": "string", "required": false, "default_value": "branch" }, { "name": "source_ref", "path": "pull_request.head.ref", "type": "string", "required": false, "default_value": "main" }, { "name": "pull_request_id", "path": "pull_request.number", "type": "integer", "required": false }, { "name": "pull_request_title", "path": "pull_request.title", "type": "string", "required": false }, { "name": "commit_hash", "path": "pull_request.head.sha", "type": "string", "required": false } ] } }' ``` > Devopness authenticates webhook calls using [hash-based message authentication code (HMAC)](https://en.wikipedia.org/wiki/HMAC); in summary, a request is considered valid when it provides the header `` with the request body encoded using the `` and a secret, provided to you by Devopness 2. From the previous command response, copy the field `url` and `secret` > `url` is the hook unique URL used to integrate with external services and `secret` is the signature key used to authenticate your webhook calls; this is the only time the secret' value will be returned as text, later operations will mask it ## Step 3: Ensure the webhook was created correctly [#step-3-ensure-the-webhook-was-created-correctly] 1. On your local machine, in a terminal window, run command to list all the pipeline webhooks, replacing ``. ```bash curl --request GET \ --url https://api.devopness.com/pipelines//hooks \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' ``` 2. In the previous command response, the recently created hook will be included in the list. # Create an Outgoing Webhook Outgoing Webhooks are a simple way integrate your Devopness environment with external services, triggering a request when an action of a resource has its state updated. Some use cases of resource action state updates are “a new application deployment is done”, “the server is now stopped” and many more use cases that can benefit from webhooks integration. Learn how to create an outgoing webhook to comment the application deploy status on a Pull Request/Merge Request. Webhooks, for now, are an API only feature; so this post will guide you through the usage of our API to help you create an outgoing webhook. 1. Make sure you have API access by following the instructions in [Devopness API Reference](/api) 2. Take note of the ID (``) of a pipeline that runs the `deploy` operation for the application which you want to watch the action statuses * Follow the [Deploy Application using an Incoming Hook](/applications/deploy-application-using-incoming-hook) guide for detailed instructions 3. On your local machine, in a terminal window, submit a request to Devopness API endpoint `POST /users/login` using your Devopness account email and password ```bash curl --request POST \ --url https://api.devopness.com/users/login \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{ "email": "", "password": "" }' ``` 4. From the previous command response, copy the field `access_token` 5. Take note of the `Target URL` (``), `Request Headers` (``) and `Request Body` (``) fields according to the source provider where the application' source code is hosted, by following the source provider's instructions on the links bellow: * [Bitbucket](https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pullrequests/#api-repositories-workspace-repo-slug-pullrequests-pull-request-id-comments-post) * [Github](https://docs.github.com/en/rest/issues/comments#create-an-issue-comment) * [Gitlab](https://docs.gitlab.com/ee/api/notes.html#create-new-issue-note) 6. On your local machine, in a terminal window, submit a request to Devopness API endpoint `POST /pipelines/:id/hooks/outgoing` to create an outgoing webhook to comment on the Pull Request using the source provider where the application' source code is hosted. In the example below, replace ``, ``, `` and `` with the actual values of each parameter before submitting the request. ```bash curl --request POST \ --url https://api.devopness.com/pipelines//hooks/outgoing \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "name": "CD(deploy)", "action_type": "deploy", "target_url": "https:///{{ action.triggered_from.hook_parsed_variables.pull_request_id }}", "settings": { "request_headers": [ { "name": "Authorization", "value": "Bearer {{ application.source_provider.access_token }}" } // NOTE: add Request Headers (``) here ], "request_body": { // NOTE: review the fields below according to Request Body (``) "body": "Deployed pipeline for `PR #{{ action.triggered_from.hook_parsed_variables.pull_request_id }} ({{ action.triggered_from.hook_parsed_variables.pull_request_title }})`: Devopness application `{{ application.name }}` deployment **{{ action.status }}** on action using [commit](https://github.com/devopness/devopness-site/commit/{{ action.triggered_from.hook_parsed_variables.commit_hash }})" } }, "trigger_when": { "events": [ "action.status_changed" ] } }' ``` 7. On your local machine, in a terminal window, run command to list all the pipeline webhooks, replacing ``. ```bash curl --request GET \ --url https://api.devopness.com/pipelines//hooks \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' ``` 8. In the previous command response, the recently created hook will be included in the list # Webhooks In this section you will learn how to create webhooks to receive events from external systems and to notify external systems of events that triggered on your applications and infrastructure environments. # Add a Team Membership Add a team to an environment with a role so all members of that team get the same access. ## Goal [#goal] Grant one team the same access to an environment through one role assignment. ## Prerequisites [#prerequisites] * Team and role created in the organization * Permission to manage team memberships ## What you need [#what-you-need] ### Team [#team] The team that should get access to this environment. ### Role [#role] The role that defines what that team can do in this environment. ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Add the `backend` team to Production with the Developer role" * "Grant the `ops` team access to Staging in `acme-platform`" ## After you save [#after-you-save] * Members of the team can access the environment based on the role * The new membership appears in the list ## Verify [#verify] * The team appears in the environment team memberships list * The assigned role matches what you intended ## Common issues [#common-issues] * Role not sufficient: check role details and permissions * Team not listed: verify the team exists in the organization ## What to do next [#what-to-do-next] * [List team memberships](/docs/environments/team-memberships/list-team-memberships) * [Teams](/docs/teams/) and [Roles](/docs/roles/) # Team Memberships Team memberships connect a team to an environment with a role. ## About [#about] * Memberships are configured per environment * Teams and roles are managed at the organization level * The role controls what the team can do in that environment ## Who this is for [#who-this-is-for] * Project admins controlling project-wide access * Environment admins setting per-environment access ## Why this exists [#why-this-exists] * It is how you give a team access to one environment * The role defines what members of that team can do there ## Relationship to other concepts [#relationship-to-other-concepts] * Teams group people * Roles define actions * Memberships attach a team and role to a specific environment ## Start here [#start-here] * Review existing team links in [List Team Memberships](/docs/environments/team-memberships/list-team-memberships) * Add a new access link with [Add a Team Membership](/docs/environments/team-memberships/add-team-membership) * Manage teams and roles first in [Teams](/docs/teams) and [Roles](/docs/roles) # List Team Memberships List teams that have access to one environment and the role each team has. ## Goal [#goal] Check current team access before you add or change memberships. ## What you need [#what-you-need] * Access to the target environment * Permission to view environment memberships ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "List team memberships in the Production environment" * "Show which teams have access to Staging in `acme-platform`" ## What you see [#what-you-see] * Each team linked to the environment * The role assigned to each team ## Verify [#verify] * The list shows the teams and roles you expected * Permissions match what you need for this environment ## Common issues [#common-issues] * List is empty: confirm teams and roles exist in the organization * You cannot open the list: check environment permissions ## What to do next [#what-to-do-next] * [Add a team membership](/docs/environments/team-memberships/add-team-membership) # Add a Personal Access Token Create a Personal Access Token for user-level automations. ## Goal [#goal] Generate a token that can do actions your user account can perform. ## What you need [#what-you-need] * A signed-in account on the Devopness web app * A clear purpose for the token so you can revoke it later when it is no longer needed To create it: 1. Open your user profile menu 2. Select `Personal Access Tokens` 3. Click `ADD PERSONAL ACCESS TOKEN` 4. Follow the prompts and confirm ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Create a personal access token for my Devopness account." * "List my personal access tokens and tell me which ones are still active." ## Verify [#verify] * A new token is created for your account * You copy and store the token value immediately, because it is shown only once ## Common issues [#common-issues] * You cannot see the token menu: confirm you are logged in and authorized * The token is not created: confirm required fields and retry * You lost the token value after closing the page: tokens are shown only once, so create a new one and revoke the old ## What to do next [#what-to-do-next] * [View a Personal Access Token](/docs/api-tokens/personal-access-tokens/view-personal-access-token) to review its details * [Revoke a Personal Access Token](/docs/api-tokens/personal-access-tokens/revoke-personal-access-token) when it is no longer needed # Personal Access Tokens A Personal Access Token is a credential that authenticates to the Devopness API as a specific user. It inherits the permissions of the user who owns it, so it can access resources and perform actions the same way that user can. ## About [#about] * A Personal Access Token behaves like the owner, with the same capabilities and permissions * It can work across all projects the user owns or is invited to as a team member * It replaces a password for API authentication in scripts, local tooling, and automations ## Who this is for [#who-this-is-for] * Developers who run scripts or CLI commands against the Devopness API * Anyone integrating personal tooling with their own Devopness account * Team members who need user-like access for one-off automations ## Why this exists [#why-this-exists] Personal Access Tokens give you a way to authenticate to the API without sharing your password, while keeping the access tied to your user identity and permissions. ## Relationship to other concepts [#relationship-to-other-concepts] * **API Tokens** group both Personal Access Tokens and Project API Tokens * **Project API Tokens** are scoped to a single project and are safer for shared or recurring automation * **Roles and permissions** control what a token owner (and therefore the token) can do ## Which token should I use [#which-token-should-i-use] Use a Personal Access Token when you need user-like access, such as quick scripts and personal tooling. For service-to-service or shared automations, prefer a [Project API Token](/docs/api-tokens/project-api-tokens/index), which keeps the permission scope smaller. ## Start here [#start-here] * [List Personal Access Tokens](/docs/api-tokens/personal-access-tokens/list-personal-access-tokens) * [Add a Personal Access Token](/docs/api-tokens/personal-access-tokens/add-personal-access-token) # List Personal Access Tokens Review all Personal Access Tokens for your account. ## Goal [#goal] Find active tokens and verify which one is being used. ## What you see [#what-you-see] * Every Personal Access Token you own, with its status and last use * A way to open a token for details or jump to revoke it ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "List my personal access tokens." * "Show me which of my personal access tokens are expiring soon." ## Verify [#verify] * You can see all Personal Access Tokens you own * You can identify which token is still active and which is revoked ## Common issues [#common-issues] * The list is empty: create a token first * A token is missing: confirm you are using the right account ## What to do next [#what-to-do-next] * [Add a Personal Access Token](/docs/api-tokens/personal-access-tokens/add-personal-access-token) to create a new one * [View a Personal Access Token](/docs/api-tokens/personal-access-tokens/view-personal-access-token) to review details # Revoke a Personal Access Token Revoke a Personal Access Token immediately. ## Goal [#goal] Stop a token from being used after it is no longer needed or has been exposed. Revoking a token is permanent. A revoked token cannot be restored. ## What you need [#what-you-need] * The Personal Access Token you want to revoke * Confirmation that the token is no longer needed, because revocation is permanent To revoke it: 1. Open `Personal Access Tokens` 2. Select the token you want to revoke 3. Click `REVOKE` 4. Confirm `REVOKE TOKEN` ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Revoke the `ci-deploy` personal access token for my Devopness account." * "Revoke the personal access token named `ci-deploy` and then confirm it is no longer active." ## Verify [#verify] * The token can no longer authenticate requests * Its status changes to revoked in the list ## Common issues [#common-issues] * You cannot revoke it: confirm you have permission to manage the token * A revoked token still appears active: refresh the list ## What to do next [#what-to-do-next] * [Add a Personal Access Token](/docs/api-tokens/personal-access-tokens/add-personal-access-token) to replace a revoked token # View Personal Access Token Review one token's key details before using it. ## Goal [#goal] Confirm token identity, state, and intended usage. ## What you see [#what-you-see] * The token's name, status, and expiry * Its last used date, so you can tell whether it is still in use * A way to decide whether the token should be updated or revoked ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "Show the details of my `ci-deploy` personal access token." * "Tell me when my `ci-deploy` personal access token was last used." ## Verify [#verify] * You know whether the token is valid and currently usable * You can decide if it should be updated or revoked ## Common issues [#common-issues] * You cannot open the token: confirm you have permission and own the token ## What to do next [#what-to-do-next] * [Revoke a Personal Access Token](/docs/api-tokens/personal-access-tokens/revoke-personal-access-token) when it is no longer needed # Add a Project API Token Generate a new project-scoped token for tools and automations. ## Goal [#goal] Create a token that can only access one project. ## What you need [#what-you-need] * A project where you can manage API tokens * A clear purpose and a role for the token, so it gets only the permissions it needs To create it: 1. Open the target project 2. Open `API Tokens` 3. Click `VIEW ALL` 4. Click `ADD API TOKEN` 5. Follow the prompts, choose the role, and confirm ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme-inc`, project `acme-platform`, create a project API token with deploy-only permissions." * "In organization `acme-inc`, project `acme-platform`, add a project API token for the CI pipeline and set its role." ## Verify [#verify] * A new project API token is created * You copy and store the token value immediately, because it is shown only once at creation time * The token has access only to the resources of the selected project ## Common issues [#common-issues] * You cannot add a token: confirm your role in the project * You cannot copy the token later: the token is shown only once, so store it right away ## What to do next [#what-to-do-next] * [View a Project API Token](/docs/api-tokens/project-api-tokens/view-project-api-token) to review its scope * [Revoke a Project API Token](/docs/api-tokens/project-api-tokens/revoke-project-api-token) when it is no longer needed # Project API Tokens A Project API Token is a credential scoped to a single project. It is the safer choice for service-to-service and CI/CD flows where least-privilege access is required. ## About [#about] * Access is limited to resources in the selected project * RBAC controls what each token can do within that project * User-level account data, such as user details and invitations, is not exposed ## Who this is for [#who-this-is-for] * Teams and automations that need recurring access to one project * CI/CD pipelines and service accounts that should not use a user's personal token * Anyone who wants least-privilege, production-safe API access ## Why this exists [#why-this-exists] Project API Tokens keep permission scope small. Instead of a token that can act as a user across everything, a project token can only reach the resources of the project you choose. ## Relationship to other concepts [#relationship-to-other-concepts] * **API Tokens** group both Project API Tokens and Personal Access Tokens * **Personal Access Tokens** inherit a user's full permissions and are better for one-off, personal tooling * **Roles and permissions** control what each token can do inside the project ## Which token should I use [#which-token-should-i-use] Use a Project API Token when a service needs recurring access to one project, when multiple people share the automation, or when you want production-safe access. For personal, temporary, or user-like tasks, use a [Personal Access Token](/docs/api-tokens/personal-access-tokens/index). ## Start here [#start-here] * [List Project API Tokens](/docs/api-tokens/project-api-tokens/list-project-api-tokens) * [Add a Project API Token](/docs/api-tokens/project-api-tokens/add-project-api-token) # List Project API Tokens Find all project-scoped API Tokens for one project. ## Goal [#goal] Pick the right token for a given automation run or service. ## What you see [#what-you-see] * Token status, scope, and usage per token * A way to open one token for details ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme-inc`, project `acme-platform`, list the project API tokens." * "In organization `acme-inc`, project `acme-platform`, show me which project API tokens are still active." ## Verify [#verify] * You can see all project API tokens for the selected project * You can identify which token fits the automation and which has the right scope ## Common issues [#common-issues] * The list is empty: create a token first * A token is missing: confirm you are looking at the right project ## What to do next [#what-to-do-next] * [Add a Project API Token](/docs/api-tokens/project-api-tokens/add-project-api-token) to create a new one * [View a Project API Token](/docs/api-tokens/project-api-tokens/view-project-api-token) to review details # Revoke a Project API Token Revoke a project token you no longer trust or need. ## Goal [#goal] Stop token authentication for that project immediately. Revoking a token is permanent. A revoked token cannot be restored. ## What you need [#what-you-need] * The project API token you want to revoke * Confirmation that the token is no longer needed, because revocation is permanent To revoke it: 1. Open the target project 2. Open `API Tokens` and `VIEW ALL` 3. Select the token to revoke 4. Click `REVOKE` and confirm ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme-inc`, project `acme-platform`, revoke the `ci-pipeline` project API token." * "In organization `acme-inc`, project `acme-platform`, revoke the project API token that was exposed." ## Verify [#verify] * The token stops authenticating requests * The list updates with a revoked status ## Common issues [#common-issues] * You cannot revoke the token: confirm your permissions in the project * A revoked token still appears active: refresh the list ## What to do next [#what-to-do-next] * [Add a Project API Token](/docs/api-tokens/project-api-tokens/add-project-api-token) to replace a revoked token # View Project API Token Review one project token's settings and status. ## Goal [#goal] Validate what a token can access before using it in production. ## What you see [#what-you-see] * The token's name, role, and expiration * Its usage details, so you can tell whether it is still in use * Its scope within the project ## Using Devopness MCP [#using-devopness-mcp] Try these prompts in Devopness MCP: * "In organization `acme-inc`, project `acme-platform`, show the details of the `ci-pipeline` project API token." * "In organization `acme-inc`, project `acme-platform`, tell me what the `ci-pipeline` project API token is allowed to do." ## Verify [#verify] * You can confirm whether the token has the right scope and role * You can decide whether to keep it or revoke it ## Common issues [#common-issues] * You cannot open the token: confirm you have permission and are looking at the right project ## What to do next [#what-to-do-next] * [Revoke a Project API Token](/docs/api-tokens/project-api-tokens/revoke-project-api-token) when the token is no longer needed # Add Step to Pipeline Add a pipeline step to perform a specific task in a defined order during the resource deployment process of your pipeline. 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card to see a list of existing `Applications` 4. In the list of applications, find the application with the pipeline you want to manage and click the `NAME` of the application 5. Click the `Pipelines` tab 6. In the list of pipelines, find the pipeline you want to manage and click the `NAME` of the pipeline 7. On the upper-left corner of pipeline details view click Pipeline Steps. 8. On the upper-right corner of the list click `ADD PIPELINE STEP` 9. Follow the instructions in the add pipeline step form then click `CONFIRM` 10. In the `Pipeline Steps` list, the recently created `Pipeline Step` can be seen > A new deployment is required for your changes to take effect. * Follow the guide [Deploy Application](/applications/deploy-application) # Pipeline Steps # Remove Step from Pipeline Learn how to remove a step from a pipeline when it's no longer needed 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card, to see a list of existing `Applications` 4. In the list of applications, find the application with the pipeline you want to manage and click the `NAME` of the application 5. Click the `Pipelines` tab 6. In the list of pipelines, find the pipeline you want to manage and click the `NAME` of the pipeline 7. On the upper-right corner of the pipeline details view, click `STEPS` to see a list of existing pipeline steps 8. In the list of pipeline steps, find the pipeline step you want to remove and click `REMOVE` 9. Follow the prompts then click `REMOVE` 10. In the list of pipeline steps, the recently removed `Step` will be gone > A new deployment is required for your changes to take effect. * Follow the guide [Deploy Application](/applications/deploy-application) # View Step in Pipeline Learn how to view the details of a specific step within a pipeline, including its action, order, and configuration. 1. On Devopness, navigate to a project then select an environment 2. Find the `Applications` card 3. Click `View` in the `Applications` card to see a list of existing `Applications` 4. In the list of applications, find the application with the pipeline you want to manage and click the `NAME` of the application 5. Click the `Pipelines` tab 6. In the list of pipelines, click the `NAME` of the pipeline you want to view 7. Click the `STEPS` tab to see a list of existing pipeline steps 8. In the list of pipeline steps, click the `NAME` of the step you want to view 9. Review the step details, including action, order, and configuration # Invite Team Member Invite one person to a team, or create a public link to share with a group. ## Goal [#goal] Add one person through a private invite, or generate a public link for a wider audience. ## Who should use this [#who-should-use-this] * Team admins adding new collaborators * Owners managing team setup ## You need [#you-need] * Team admin access in the target organization * Permission to send team invitations ## Steps [#steps] 1. Open the organization that owns the team 2. Open `Teams` and select the target team 3. Open `Invitations` 4. Choose one path: * Private invite: enter one email address * Public invite: open the public invite flow 5. For private: enter the person's email address 6. For public: generate the invitation link and copy it 7. Confirm to create the invitation ## Expected result [#expected-result] * A new private invite or public link is created * The recipient can accept and join the team ### Security note [#security-note] Use private invites by default. Use a public link only when you want to add many people from a known group at once. ## Common issues [#common-issues] * Invite is rejected: confirm the email is valid for private invitations * Public link is missing or expired: generate a new link and share it again * Invite is blocked: verify sender permissions for team invitations ## Next [#next] * Grant team access to environments in [Team Memberships](/docs/environments/team-memberships) # Team invitations Team invitations are how you add people to a team so the team can access resources in one organization, project, or environment. You can use two invitation types: * Public invitation: Devopness creates a join link you can share with many people. This is useful for communities or team channels where you want fast onboarding. * Private invitation: you enter one email address, and the invite is sent only to that person. If you want the tighter security default, use private invitations. Use public links only when you are intentionally opening team access to a wider audience. ## About [#about] * Invitations are sent to people not yet in the team * Private invites go to one email address, while public invites use a shared link * Once accepted, the member joins the team and gets that team’s access * Team access still depends on roles assigned at organization, project, or environment scope ## Who this is for [#who-this-is-for] * Team admins adding collaborators * Organization owners onboarding users in bulk or in groups ## Why this exists [#why-this-exists] * It keeps invite flow clear as organizations grow * It helps avoid giving people direct environment access before the team role is set ## Relationship to other concepts [#relationship-to-other-concepts] * Invitations apply to teams in an organization * Team memberships apply role-based permissions at organization, project, or environment level ## Start here [#start-here] * Send one invitation in [Invite Team Member](/docs/teams/invitations/add-invitation) * Review invite status in [List Team Invitations](/docs/teams/invitations/list-invitations) * Manage invites sent to you in [Received Invitations](/docs/users/teams/invitations/list-invitations) # List Team Invitations Track the status of team invites, both private and public, before they are accepted. ## Goal [#goal] Know which invites are pending, accepted, or expired before you grant broader access. ## Who should use this [#who-should-use-this] * Team admins adding collaborators * Organization owners checking invitation workflow ## You need [#you-need] * Team admin access in the organization * Invite sending enabled for the team ## Steps [#steps] 1. Open the organization and the team you manage 2. Open `Invitations` 3. Review pending, accepted, and expired items 4. Open an invite if you need to resend or revoke it ## Expected result [#expected-result] * You can see current invite state for the team * You can clean up stale invites before they become confusing ## Common issues [#common-issues] * No invite list: confirm you are on the correct team * Missing status: refresh the page after changing invite state ## Next [#next] * Send a new invite in [Invite Team Member](/docs/teams/invitations/add-invitation) 1. On Devopness upper-left corner, click the Devopness logo to see a list of existing projects 2. In the list of `Projects` find the `Project` with the `Team` you want to manage and click `View` 3. In the list of Project resources find the `Teams` card and click `View` 4. In the list of `Teams` find the `Team` you want to view invitations for and click `View` 5. On the upper-right corner of the team details view, click `INVITATIONS` 6. In the `Invitations` list, you can see: * **Email**: The email address of the invited member * **Type**: `private` for one-email invites, `public` for link invites * **Status**: Current status of the invitation (Pending, Accepted, Expired) * **Invited by**: Who sent the invitation * **Invited at**: When the invitation was sent * **Expires at**: When the invitation expires 7. Use the search and filter options to find specific invitations 8. Click on any invitation to view more details or take actions like resending or canceling # Members A team member is a user invited to join a team. After accepting, the member gets the same access as other people in that team: based on the role assigned to the team at the organization, project, or environment level. ## About [#about] * Members are invited to a specific team, and that team can be attached to one or more projects or environments * A member can join multiple teams in the same organization ## Who should use this [#who-should-use-this] * Team admins keeping team access current * Organization owners checking who can access shared resources ## Why this exists [#why-this-exists] * It is easier to add and remove people from one team than from every project or environment ## Relationship to other concepts [#relationship-to-other-concepts] * Teams are organized by organization * Roles control what a member can do through team membership in an environment ## Start here [#start-here] * Add team members by inviting users in [Invite Team Member](/docs/teams/invitations/add-invitation) * Track invites and statuses in [List Team Invitations](/docs/teams/invitations/list-invitations) # Cancel Active Subcription Plan Sometimes the project needs may change and the current active plan does not fit your project needs. Cancel your currently active plan to ensure you will no longer be charged on that plan. 1. On Devopness, in the upper-right corner of any page, click your profile icon then click `Billing & plans` 2. Click `MANAGE YOUR PLAN` > This will redirect you to the billing management page 3. In `Current subscription` section, click `Cancel my subscription` 4. Follow the prompts to complete the subscription cancellation # Billing and Plans Learn how to manage your subscription plan on Devopness. ## About billing for Devopness plans and actions [#about-billing-for-devopness-plans-and-actions] Devopness usage is free for everyone, without any limits on the amount of projects, environments or the amount of resources that can be added to each project environment. Paid subscription plans are available for users and teams who want to increase their productivity by taking the most of Devopness additional features. Independently of the subscription plan of a Devopness project, the main usage is controlled by credits. Devopness consumes one credit per completed action step when running a pipeline Each Devopness user account receives a certain amount of credits monthly, depending on the user’s active subscription plan. Credits are consumed from the project owner’s account: if you are collaborating on somebody else’s project as a team member, but you’re not the owner of that project, then your credits will not be consumed when working on that project. For details, see Usage limits and our [FAQ](/users/subscriptions/faq) ## Billing date and subscription renewal [#billing-date-and-subscription-renewal] You can view your account's subscription details, payment history and your next billing date in your account's billing settings at [Upgrade your Devopness Subscription](/users/subscriptions/upgrade-subscription) ## Billing settings [#billing-settings] You can manage your billing settings, such as subscription plans and payment methods in your account's billing settings at [Upgrade your Devopness Subscription](/users/subscriptions/upgrade-subscription) ## Overages [#overages] At the moment Devopness does not allow usage-based billing, so user projects cannot consume more credits than the amount included in the user’s active subscription plan. There will be no surprises in your monthly or annual billing, as Devopness will charge you upfront for the included amounts of credits in your subscription plan. You can see the amount of credits included in your account's billing settings at Billing & Plans ## Usage limits [#usage-limits] There are some limits when using Devopness actions, depending on the subscription plan. These limits are subject to change every time our plans are updated. For details, see our [pricing page](https://www.devopness.com/pricing/) Below you have a table with the current applied limits, per plan, followed by an explanation on the impact of each limit: | | Free | Standard | | :----------------------------------------------------------- | :--------- | :--------- | | **Max parallel actions, per server** | 1 | 10 | | **Max parallel actions, per pipeline** | 1 | 10 | | **Max amount of time an action step log remains accessible** | 24 hours | 90 days | | **Max execution time, per action step** | 10 minutes | 15 minutes | | **Max API requests, per minute** | 30 | 120 | * **Max parallel actions, per server**: Users can control how many actions can run simultaneously on each server, so the server resources are used the way that is most suitable for each user environment * **Max parallel actions, per pipeline**: User pipelines may run custom action steps that could lead to race conditions if executed concurrently. Devopness allows user to define which pipelines can have multiple actions executing it at the same time and how many parallel actions are allowed to be started running that pipeline. * **Max execution time, per action step**: Each pipeline step executed by an action can run for up to 15 minutes of execution time. If an action step reaches this limit, the step is moved to the “failed” status and the action fails to complete. ## Usage policy [#usage-policy] In addition to the usage limits, you must ensure that you use Devopness within our [Terms of Service](/legal/terms-of-service) # Upgrade your Devopness Subscription Your projects can benefit from advanced features or need extra credits to reach its demands. Upgrade your subscription at any time to ensure your team can access all benefits of managing your projects with Devopness. 1. On Devopness, in the upper-right corner of any page, click your profile icon then click `Billing & plans` 2. Click `MANAGE YOUR PLAN` > This will redirect you to the billing management page 3. In `Subscribe to Devopness` section, select a plan then click `Choose Plan` 4. Add your email and country then click `Continue` 5. Add your payment information then click `Subscribe Now` > If you have a coupon, click `+ Add discount`, insert the code then click `Apply` 6. Click `Back to Devopness` > The subscription plan info should be updated with your new paid plan # Received Invitations Manage received team invitations and accept or decline them. ## Goal [#goal] Know where to find and manage your received invitations. ## Who should use this [#who-should-use-this] * Team collaborators who are joining an organization/environment ## You need [#you-need] * A valid Devopness account with an existing email ## Steps [#steps] 1. In any page within the Devopness app, click your profile button at the top right 2. Select [`Teams Invitations`](https://app.devopness.com/profile/teams/invitations) 3. Now in the invitations view either accept or decline an invite *OR* 1. Check your e-mail for a new mail from Devopness 2. There should be a brief summary of who invited you, to which organization and which team 3. Click the `VIEW INVITATION` button, you will be redirected to the `Teams Invitations` page 4. Now in the invitations view either accept or decline an invite ## Expected result [#expected-result] * You can see the invitations you have received * You can accept or decline an invite ## Common issues [#common-issues] * No invitations found: confirm with a organization admin that you have been invited * Missing invite: refresh the page after an admin invites you ## Next [#next] * After accepting an invite, check whether you now have access to that organization 1. On the upper-left corner, click the Devopness logo to [see all available organizations to you](https://app.devopness.com/organizations) 2. Select the organization of the recent accepted invite 3. From that point on get in contact with your organization admin for any needed permissions (see [roles](/docs/roles)) # FAQ ## Is Devopness Free? [#is-devopness-free] All Devopness users and teams get FREE FOREVER access to manage a limited number of projects, environments and resources in any supported cloud provider, and can also deploy application code from `git` repositories hosted in any supported source provider. All your projects can have teams and users collaborating on it, for FREE. When your projects grow you may need more deployment options, security controls and collaboration features that may require upgrading to a paid plan. See also: * [What Devopness users pay for?](#what-devopness-users-pay-for) * [Pricing](https://www.devopness.com/pricing/) ## What Devopness users pay for? [#what-devopness-users-pay-for] You pay for action steps that Devopness executes for you. As an action running a pipeline can have a variable number of steps, Devopness will charge you by consuming one credit for each action step executed. Paid plans also differ in the number of premium features available to increase your team's productivity. See also: * [What are actions and action steps?](#what-are-actions-and-action-steps) * [What are credits?](#what-are-credits) * [Pricing](https://www.devopness.com/pricing/) ## How do I pay? [#how-do-i-pay] You can pay inside the Devopness web app. For detailed instructions, see: * [Upgrade your Devopness Subscription](/users/subscriptions/upgrade-subscription). ## What are actions and action steps? [#what-are-actions-and-action-steps] An “action” is the execution of a pipeline. As in our daily routine of managing software projects we need to “take an action” to fix or improve something, that’s exactly what Devopness does for you and your team. Devopness creates an “action” every time you need to run a pipeline to perform single-step or multi-step operations on resources in your project environments. Each step in a pipeline becomes an action step, that is then executed by Devopness according to how a pipeline was configured at that point in time. For your convenience, each action step output log is made available for you in Devopness action details view. See also: * [Actions](/actions) ## What are credits? [#what-are-credits] Credit is the unit used to pay for each action step Devopness executes for you when running pipelines in your project environments. ## How are credits used by Devopness? [#how-are-credits-used-by-devopness] As an action running a pipeline can have a variable number of steps, Devopness will charge the project owner by consuming one credit for each **successful action step completed**. By default, many actions involve only one step and therefore consume just 1 credit. However, more complex actions—such as large application deployments or pipelines with multiple steps—will require additional credits based on the number of **successful steps** involved. For example: * A simple action with one successful step, like a basic task or deployment, will consume **1 credit**. * A pipeline with 5 successful steps will consume **5 credits**, as one credit is deducted for each successfully completed step. This ensures that credit consumption reflects the complexity and success of each action. See also: * [What are actions and action steps?](#what-are-actions-and-action-steps) * [What are credits?](#what-are-credits) ## Am I charged for `failed` and `skipped` action steps? [#am-i-charged-for-failed-and-skipped-action-steps] No. Devopness only consumes credits for successfully completed steps. While an action step in `pending`, `waiting`, `queued` or `in progress` status, no credit is consumed from your subscription balance. Also, when steps are not successfully completed for being `skipped` or have `failed` Devopness will not charge you for that action step. ## Are my credits used when contributing to someone else's project? [#are-my-credits-used-when-contributing-to-someone-elses-project] No. Only the owner of a project is charged for action steps in their projects. ## How can I see how many credits I have and how many I used? [#how-can-i-see-how-many-credits-i-have-and-how-many-i-used] You can see your total and remaining credits by accessing `Billing and Plans` in your Devopness profile. For detailed instructions, see: * [Billing and Plans](/users/subscriptions) ## What happens when I run out of credits? [#what-happens-when-i-run-out-of-credits] If you run out of credits you can keep using Devopness to manage your environment resources and all features on your paid plans will remain accessible. However, new actions will still be created with status `failed`. Those actions will not be executed and you will see the error message below: ``` Insufficient credits to run this action ``` When that happens, you can fix the error by adding more credits to your account. For more information, see: * [How do I add credits to my account?](#how-do-i-add-credits-to-my-account) ## How do I add credits to my account? [#how-do-i-add-credits-to-my-account] To add credits to your account, [Upgrade your Devopness Subscription](/users/subscriptions/upgrade-subscription). ## When is my subscription renewed? [#when-is-my-subscription-renewed] Monthly. The exact date may vary as months have different number of days. We currently renew subscriptions every 30 days from the day an account subscription was updated, upgraded or downgraded ## What happens if my subscription cannot be renewed? [#what-happens-if-my-subscription-cannot-be-renewed] Subscriptions are renewed automatically on their expiry date, using your chosen payment method. If for some reason your subscription could not be renewed, the current subscription will be canceled. See also: * [What happens after my subscription is canceled?](#what-happens-after-my-subscription-is-canceled) ## How do I cancel my subscription? [#how-do-i-cancel-my-subscription] Subscriptions on Devopness are for an indefinite term, unless you unsubscribe. Upon cancellation, your subscription will remain active and its credits can be used until the end of the current paid term. See also: * [Cancel Active Subcription Plan](/users/subscriptions/cancel-subscription) * [What happens after my subscription is canceled?](#what-happens-after-my-subscription-is-canceled) ## What happens after my subscription is canceled? [#what-happens-after-my-subscription-is-canceled] When your subscription is canceled you’ll still be able to use your subscription exclusive features and remaining credits for the time you’ve already paid for. For example, if you buy a monthly subscription on January 10 and decide to cancel it on January 20: * You’ll have access to the subscription features and credits until February 9 (30 days after initial purchase); * You won’t be charged another monthly subscription on February 9. A few things will happen: 1. Your subscription will be downgraded to the FREE plan; 2. You can still access action details and action steps output logs, but limited to actions created in the last 24 hours; 3. In environments using custom [Roles](/roles) in their [Team Memberships](/environments/team-memberships), the membership will be updated to use the role “Read”, converting all users to read-only users. But don’t worry: your data will not be lost and your configurations, including team membership roles, will be restored once you update your payment methods and upgrade again to a paid plan.