# Salus Cloud — full site content > The complete prose of every page on salus.cloud in one file, for agents and > retrieval systems that would otherwise crawl 51 URLs. Each chapter is the > same markdown that https://salus.cloud serves at that URL under `Accept: text/markdown`. > > Index and orientation: https://salus.cloud/llms.txt > Machine-readable endpoint spec: https://salus.cloud/openapi.json > Generated at build time (2026-08-25). Do not edit by hand. ## Contents - [Salus | Run AI- and Citizen-Built Apps in Your Own Cloud](https://salus.cloud/) - [Salus platform — runtime, delivery, AI ops, control](https://salus.cloud/platform/) - [Salus for builders — build with anything, ship in your cloud](https://salus.cloud/builders/) - [Salus for enterprise — the governed lane, in your own cloud](https://salus.cloud/enterprise/) - [Salus pricing — pay for builders and what runs; app users are free](https://salus.cloud/pricing/) - [Salus Cloud Developer & Agent Resources — MCP Server, CLI, OpenAPI | Salus](https://salus.cloud/developers/) - [Introduction — Salus Docs](https://salus.cloud/docs/) - [Agents on Salus — any agent ships, governed](https://salus.cloud/agents/) - [Salus Changelog — Product Updates & Release Notes](https://salus.cloud/changelog/) - [Flexible configuration, smarter automation, and clearer billing — Salus Changelog](https://salus.cloud/changelog/changelog-03262026/) - [Pipeline visibility and security hardening — Salus Changelog](https://salus.cloud/changelog/changelog-04152026/) - [RBAC on space and project level — Salus Changelog](https://salus.cloud/changelog/changelog-05052026/) - [Rollbacks and general platform enhancements — Salus Changelog](https://salus.cloud/changelog/changelog-05102026/) - [Trusted devices, developer tooling, and reliability upgrades — Salus Changelog](https://salus.cloud/changelog/changelog-06112026/) - [Supply-chain security and tighter login controls — Salus Changelog](https://salus.cloud/changelog/changelog-06162026/) - [Security visibility, clearer costs, and a smoother platform — Salus Changelog](https://salus.cloud/changelog/changelog-07072026/) - [Salus MCP v0.18.0 — rollbacks, security insight, and safer agent deploys — Salus Changelog](https://salus.cloud/changelog/changelog-07132026/) - [Database linking, live activity notifications, and a cleaner dashboard — Salus Changelog](https://salus.cloud/changelog/changelog-07202026/) - [Contact Salus — start, demo or deploy in your cloud](https://salus.cloud/contact/) - [Billing Dashboard — Salus Docs](https://salus.cloud/docs/account-and-billing/billing-dashboard/) - [Salus Credits — Salus Docs](https://salus.cloud/docs/account-and-billing/salus-credits/) - [CLI — Salus Docs](https://salus.cloud/docs/cli/) - [Access Control — Salus Docs](https://salus.cloud/docs/deployments/access-control/) - [Databases — Salus Docs](https://salus.cloud/docs/deployments/databases/) - [Deployments — Salus Docs](https://salus.cloud/docs/deployments/deployments/) - [Environment Configurations — Salus Docs](https://salus.cloud/docs/deployments/environment-configurations/) - [Git Management — Salus Docs](https://salus.cloud/docs/getting-started/git-management/) - [Organizations & Teams — Salus Docs](https://salus.cloud/docs/getting-started/organizations-and-teams/) - [Projects — Salus Docs](https://salus.cloud/docs/getting-started/projects/) - [Quickstart — Salus Docs](https://salus.cloud/docs/getting-started/quickstart/) - [Supported Stacks — Salus Docs](https://salus.cloud/docs/getting-started/supported-stacks/) - [Logs — Salus Docs](https://salus.cloud/docs/observability/logs/) - [Metrics — Salus Docs](https://salus.cloud/docs/observability/metrics/) - [Builds — Salus Docs](https://salus.cloud/docs/pipelines/builds/) - [Buildpacks — Salus Docs](https://salus.cloud/docs/pipelines/builds/buildpacks/) - [Custom Docker Builds — Salus Docs](https://salus.cloud/docs/pipelines/builds/custom-docker/) - [Pipeline Customization — Salus Docs](https://salus.cloud/docs/pipelines/pipeline-customization/) - [Pipeline Details — Salus Docs](https://salus.cloud/docs/pipelines/pipeline-details/) - [Pipeline Logs — Salus Docs](https://salus.cloud/docs/pipelines/pipeline-logs/) - [Pipelines Overview — Salus Docs](https://salus.cloud/docs/pipelines/pipelines/) - [Quality & Security — Salus Docs](https://salus.cloud/docs/pipelines/quality-and-security/) - [Code Analysis — Salus Docs](https://salus.cloud/docs/pipelines/quality-and-security/code-analysis/) - [Package Vulnerability Scanning — Salus Docs](https://salus.cloud/docs/pipelines/quality-and-security/package-vulnerability-scanning/) - [Unit Testing — Salus Docs](https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/) - [Salus Intelligence — Salus Docs](https://salus.cloud/docs/salus-intelligence/) - [Salus for Engineering Teams | Production in Your Own Cloud](https://salus.cloud/engineering/) - [Legal — agreements and policies | Salus Cloud](https://salus.cloud/legal/) - [Subscription Agreement (EULA) — Salus Cloud](https://salus.cloud/legal/eula/) - [Privacy Policy - Salus Cloud Corporation](https://salus.cloud/privacy-policy/) - [Security & Trust | Salus](https://salus.cloud/security/) - [Evaluate Salus | A Governed Lane for Your Teams and Their Agents](https://salus.cloud/talk-to-sales/) --- **Source:** https://salus.cloud/ Any team. Any agent. Your cloud. # Let your whole company build with AI. Salus deploys the app you already have — any framework, any agent — unchanged, as a real running service in your own cloud and region. Never rewritten to fit someone else's platform. Governed by IT; your code and data never leave your control. [Start free](https://app.salus.cloud)[Book a demo](https://salus.cloud/talk-to-sales/) Built by engineering veterans. Loved by the teams who govern it. runs: api · web · workers · agents · databases · cachesclouds: AWS · GCP · Azure · private cloud · Salus Hardware Running real production — in their own clouds ![Zedcrest logo](https://salus.cloud/assets/logos/zedcrest.svg)![Yuppiechef logo](https://salus.cloud/assets/logos/yuppiechef.svg)![Apex Networks logo](https://salus.cloud/assets/logos/apex.svg) The problem ## Everyone's building with AI. Nobody owns where it ships. Citizen developers don't write low-code anymore. They write real code — with AI. And real code needs a real, governed place to run. 1 · The mandate ### Leadership told every team to use AI. Finance, Marketing, Ops, Product and Support are already building real apps with it — with Claude, Cursor, Replit, or their own agents. 2 · The collision ### Those apps have to run somewhere. AI-built apps are real code, not low-code. Security can't let unsanctioned apps near production — so they sneak in as shadow AI, or die in the engineering queue. 3 · The resolution ### Salus is the governed lane. A lane that runs alongside production, in your own cloud, where any team and any agent ships under IT’s rules. 1 in 3 people building with AI at work have no programming background 63% of organizations have no AI governance policy covering what they build 20% of breaches now involve shadow AI — at $670K extra cost each 2× the rate at which AI-assisted code leaks secrets vs. the baseline Sources: Zapier (2026) · Cloud Security Alliance (2026) · IBM Cost of a Data Breach (2025) · GitGuardian State of Secrets Sprawl (2026). How it works ## One governed lane. Alongside prod, never inside it. IT sets the rules once. Every builder — human or agent — ships through them. step 1 ### Build with anything Any framework, any AI tool, any agent. If it builds, it ships — unchanged, as a real long-lived service in your own container. Never rewritten onto someone else’s runtime. step 2 ### Ship through your rules Roles set once at the organisation, space and project level — every app your teams ship inherits them, and any deployment can be taken offline on demand. step 3 ### Run in your own cloud Your AWS, GCP, Azure or Huawei account — or your own private cloud. Your region, your data boundary. Alongside prod — never inside it. Under the hood ## A real production platform — not a sandbox with training wheels. Real containers, real databases, real pipelines. That's why apps built here can graduate into engineering-owned production — on the same platform. With your agentWith the CLI your agent · claude codesalus · mcp Deploy my expense tracker, please. Done — it went out through your company’s governed lane. build ✓security scan ✓policy ✓live every step checked against IT’s rules · audited Is it safe? Run a security scan. Just did — 12 policies checked, nothing critical found. It feels slow this morning. Can you check the logs? Found it: the database connection pool is maxed out. I can raise it and redeploy. Rather roll back to yesterday’s version for now. Rolled back — yesterday’s version is live again. IT can see everything I did in the audit trail. rollback ✓audited salus@control-planezsh Deployment live payments-api · v1.42 · europe-west1 34s Logs streaming api · 1.2k events/min Security check passed 12 policies · 0 critical passed Agent action · rollback via MCP · scoped RBAC · audited done Prefer the full tour? [See the platform →](https://salus.cloud/platform/) For IT & security ## Security's job is to say no. Salus lets them say yes — safely. You're not adding a new place for shadow AI to hide. You're replacing the place it already hides — with one you control. ### Turn "no" into "yes, safely" Stop being the department of no. Enable the AI mandate without taking on its risk. ### Governed by default Org, space and project roles · isolated workloads · append-only audit storage · an off switch for any deployment. ### Alongside prod, never inside it The environment you’ve spent years protecting stays untouched. No vibe-coded app lands next to the crown jewels. ### Your cloud, your rules Runs in your own cloud account — data residency, your compliance boundary, no lock-in. ### Shadow AI comes into the light The apps employees already build get a place you can see, audit and control — instead of hiding in scripts and random SaaS. ### No new babysitting You don’t manage each team’s environments or apps — the platform does. Cost caps per builder and per app, built in. The full trust story, including compliance status: [Security & Trust →](https://salus.cloud/security/) Who builds here ## Who builds keeps changing. Where it ships shouldn't. One platform, three kinds of builder — each with its own RBAC and guardrail profile. Same lane, same rules, same cloud: yours. [ ### Professional engineering Real production workloads — pipelines, databases, observability, any framework. The platform your current stack would trust. See the engineering track](https://salus.cloud/engineering/)[ ### Agentic engineering Your developers and their AI agents, working over MCP. Agents deploy, roll back and read logs — with their builder’s access, never more. See how agents ship](https://salus.cloud/builders/)[ ### Citizen builders Finance, Ops, Marketing, Support — building with AI and shipping to a lane IT already governs. No engineering queue. See what teams build](https://salus.cloud/builders/) Pricing ## Pay for builders and what runs. App users are always free. Start with free credit and ship in minutes. Switch on the governed lane when you go to production. Run it in your own cloud at scale. [ ### Free $0 + consumption $10 starter credit. Up to 2 builders. ](https://salus.cloud/pricing/)[ ### Pro $9 / builder / mo Production deploys, unlimited builders, plus consumption. ](https://salus.cloud/pricing/)[ ### Enterprise From $25 / builder Governance at scale — on Salus Cloud or your own. ](https://salus.cloud/pricing/) Full details and FAQs: [Pricing →](https://salus.cloud/pricing/) ## Give shadow AI a place to land. Governed. A 30-minute technical walkthrough showing how the governed lane would work in your cloud — for your teams and their agents. [Start free](https://app.salus.cloud)[Book a demo](https://salus.cloud/talk-to-sales/) --- **Source:** https://salus.cloud/platform/ Platform # One governed lane. Four pillars. Runtime, delivery, AI-native operations and enterprise control — composable and governed end-to-end. Use one. Use all four. [Start building](https://app.salus.cloud)[For enterprise](https://salus.cloud/enterprise/) Runtime Containers, services, jobs, GPU, databases. Delivery Build, scan, policy, deploy, rollback. AI ops Explain, recommend, summarise, fix. Control RBAC, audit, BYOC, self-host, cost. substrate Multi-tenant · BYOC · Private DC · On-prem awsgcpazurehuaweisalus hardwarek8s · on-prem Capabilities ## Four pillars, in detail. [ Pillar ### Cloud Runtime Run apps, APIs, workers, databases, scheduled jobs, agents and GPU workloads — replicated across clouds and regions from the UI, or by an agent over MCP. - Containers - Services - Jobs - GPU workloads - Private networking - Secrets - Usage-based cost - Autoscaling Explore ](https://salus.cloud/platform/)[ Pillar ### Software Delivery From commit to production, with guardrails built in. - Build pipelines - Deployment workflows - Environment promotion - Rollbacks - Policy checks - Release visibility - Approvals - Drift detection Explore ](https://salus.cloud/platform/)[ Pillar ### AI-Native Operations Let agents help teams detect, explain and fix operational drift. - Explain failing deploys - Recommend infra changes - Detect security gaps - Summarise logs - Surface cost anomalies - Generate runbooks - On-call assist - Postmortems Explore ](https://salus.cloud/platform/)[ Pillar ### Enterprise Control Self-serve for builders. Controlled for the business. - RBAC for humans & agents - Audit trails - Customer-controlled envs - BYOC - Self-hosted - Customer certificates - Cost reporting - Org policy Explore ](https://salus.cloud/platform/) ## Who builds keeps changing. Where it ships shouldn't. Start in our cloud. Move to yours when you're ready. Same lane, same rules. [Start building](https://app.salus.cloud)[Deploy in your cloud](https://salus.cloud/enterprise/) --- **Source:** https://salus.cloud/builders/ For builders — human and agent # Build with anything. Ship as yours. Built it with Claude, Cursor, Replit — or your own editor? Salus takes real code from any builder, human or agent, and runs it as your own governed workload: deploys, preview environments, logs, costs and on-demand GPU. Any framework, no waiting on anyone. [Start free](https://app.salus.cloud)[See the platform](https://salus.cloud/platform/) your agent · claude codesalus · mcp Deploy my expense tracker, please. Done — it went out through your company’s governed lane. build ✓security scan ✓policy ✓live every step checked against IT’s rules · audited Is it safe? Run a security scan. Just did — 12 policies checked, nothing critical found. It feels slow this morning. Can you check the logs? Found it: the database connection pool is maxed out. I can raise it and redeploy. Rather roll back to yesterday’s version for now. Rolled back — yesterday’s version is live again. IT can see everything I did in the audit trail. rollback ✓audited API payments-api live p99 24ms · 3 regions GPU model-train-a100 scaling GPU 78% · a100 ×4 Worker ingest-worker building queue 142 Web dashboard-pr-482 live preview env For every team ## What will your team build? Every team has apps they wish they had — the spreadsheet that should be a tool, the workflow stuck in email. With AI, they can build them. Salus is where those apps run: governed, visible, and in your company's own cloud. ### Finance - Spend & budget dashboards - Approval workflows - Invoice reconciliation tools ### Marketing & Sales - Campaign microsites & landing pages - Lead-routing and scoring apps - Content and asset tools ### Operations - Internal admin tools - Inventory & logistics trackers - Process automations ### Product - Internal dashboards - Feedback & research portals - Working prototypes ### Customer Support - Ticket-triage helpers - Customer lookup apps - Knowledge tools ### Data & Analytics - Self-serve reporting apps - ML-output dashboards - Data-entry & cleanup tools CLI & MCP ## Your agent already knows how to drive it. Each command does one thing and prints what it did. And every one of them doubles as an MCP tool your agents can call — under the same RBAC and guardrails as you. `salus init` Detect your stack and scaffold a Salus project. `salus deploy` Build, scan and deploy in one step. `salus logs api` Stream structured logs by workload. `salus cost workload api` Per-workload cost in real time. `salus scale gpu-worker --gpu a100` Burst GPU on demand. `salus rollback api` Roll back to the last good revision. Built for the way you work ## Everything you need to go from idea to production. ### Zero-config deploys Push a Dockerfile, a Node app or a static site. Salus detects, builds and deploys. ### Preview environments Every PR gets an isolated preview with its own database, secrets and URL. ### Logs, traces and metrics Built-in observability — no extra agent, no extra integration to wire up. ### GPU on demand Run GPU jobs and inference workloads with a single flag. Pay for what you use. ### Secrets & networking Per-environment secrets and private networking, governed by org policy. ### MCP for agents Every operational step is an agent-callable tool — deploy, rollback, logs, databases — using the access of the builder who invoked it. From commit to production ## From 'it works on my laptop' to live — one path. Salus runs every change through the same flow — so you can move fast without losing control. 1. step 1 git push commit detected 2. step 2 build image salus.app/api:9f3c 3. step 3 scan no critical issues 4. step 4 policy release window OK 5. step 5 deploy rollout 100% 6. step 6 observe logs · traces · cost ## A software engineer? There's a track for you too — real production, pipelines, any framework, your own cloud, and agents as first-class teammates over MCP. [See the engineering track](https://salus.cloud/engineering/) ## Ship the AI apps you build — without waiting in the engineering queue. Sign up and deploy your first app in under five minutes. No credit card required. [Start free](https://app.salus.cloud)[Deploy in your cloud](https://salus.cloud/enterprise/)[See the platform](https://salus.cloud/platform/) --- **Source:** https://salus.cloud/enterprise/ For IT, security & platform leaders # The governed lane. In your own cloud. The board told everyone to build with AI. Security can't let them ship it into prod. Salus is the lane where any team — and any agent — builds and deploys into your cloud, under your rules. Alongside prod, not inside it. [Book a demo](https://salus.cloud/talk-to-sales/)[Security & trust](https://salus.cloud/security/) 99.99% Control plane uptime target < 60s Median deploy time SOC 2 \+ ISO 27001 — audits completing, 2026 BYOC AWS, GCP, Azure, Huawei or private cloud Deployment models ## Run Salus where your business needs it. The same control plane runs in our cloud, your cloud, or your own Kubernetes — without forking the developer experience. Salus CloudSalus HardwareBYOCSelf-hostedHybrid salus.cloud ### Multi-tenant Cloud For builders and teams that want to start immediately. Salus runs everything — compute, network, build, observability — on managed infrastructure. - Instant deploys - Managed regions - Prepaid credits, cost caps built in private data centers ### Salus Hardware regions Fully managed regions on Salus-owned hardware in private data centers — in-country residency with no hyperscaler in the chain. Rolling out starting with South Africa, then Nigeria. - Salus-owned infrastructure - In-country data residency - No hyperscaler dependency aws · gcp · azure · huawei ### Bring Your Own Cloud Run Salus-managed workloads inside your own AWS, GCP, Azure or Huawei account. The control plane is ours; the data plane is yours. - Your VPC - Your IAM - Your data residency k8s · on-prem ### Self-hosted on Kubernetes For regulated environments that need strict control. Run the entire Salus stack on your own Kubernetes — air-gapped if required. - Air-gap supported - Customer-controlled certificates - Full audit trail cloud + your infra ### Hybrid estate Mix Salus Cloud, BYOC and self-hosted. Run development in our cloud and production in yours — under one control plane. - Single control plane - Cross-environment promotion - Unified policy Governance ## Self-serve for builders. Controlled for the business. The controls security and platform teams need — without the friction that pushes builders back into shadow IT. ### Role-based access control Roles scoped to your organisation, spaces and projects — Owner, Maintainer, Developer, Viewer, Guest — with SSO. An agent acts with its builder’s access, so it can never reach further than they can. ### Customer-controlled environments Per-customer trust boundaries, certificates and policy — visible to your customers, governed by you. ### Append-only audit storage Events are written once and never edited or deleted, isolated per tenant at the database level, each recording the actor and the time. Coverage is expanding service by service. ### Consumption reporting See what every project and environment consumes, broken down by compute, databases and bandwidth, so finance can see where the spend goes. ### Secure delivery workflows Build, scan, policy and approval gates run before any change reaches production. ### Isolation and an off switch Each workload runs in its own isolated infrastructure, and any deployment can be taken offline on demand — from the console, the CLI or an agent tool call. The story you'll tell ## Governance you can report, not just claim. Leadership is already asking how the AI mandate is going. This is the shape of the answer a governed lane gives you — the apps, the departments, the gates that held. AI apps · quarterly update illustrative 11 apps shipped by 4 departments — finance, HR, ops, support 0 incidents from citizen- or AI-built apps 23 gates enforced risky deploys blocked before they ran — the rules, working 100% within caps every app inside its IT-set spend cap illustrative figures · roles, gates and region selection applied by the platform, not by each team BYOC architecture ## Our control plane. Your data plane. Run Salus-managed workloads inside your own AWS, GCP, Azure or Huawei account. Salus orchestrates; your cloud holds the data, identity and network. Nothing leaves your perimeter. - Workloads run in your VPC, under your IAM - Data residency stays in your region - Customer-controlled certificates and KMS - Air-gap and self-hosted available your-org-aws vpc: region: eu-west-1 cidr: 10.42.0.0/16 data\_plane: workloads: payments-api, ingest, dashboard gpu\_pool: a100 ×8 (spot) observability: enabled salus\_control\_plane: endpoint: cp.salus.cloud egress\_only: true identity: provider: okta rbac: org / space / project ## Stop being the department of no. Connect your cloud, your identity and your policies. Give every team — and their agents — a fast path your security team already trusts. [Book a demo](https://salus.cloud/talk-to-sales/)[See pricing](https://salus.cloud/pricing/) --- **Source:** https://salus.cloud/pricing/ # Salus pricing — pay for builders and what runs; app users are free Pricing ## The people who use your apps are always free. You pay for builders and admins, and for what runs — never for the colleagues and customers who use what you build. Start free, go to production at $9 per builder, and move into your own cloud when you are ready. ### Free Start building, on us. Up to two builders. $0\+ consumption - $10 starter credit when you connect your repo - Up to 2 builders - Deploy straight from your repo - Any framework, real containers - Community support [Start for free](https://app.salus.cloud) ### Pro Most teams Production apps, unlimited builders. $9per builder / mo + consumption - Everything in Free - Unlimited builders - Production deploys, your custom domains - Choose your cloud and region per environment - Serve publicly or keep it internal-only - Managed databases, provisioned with the app - SSO - Business-hours support [Start building](https://app.salus.cloud) ### Enterprise Governance and controls at scale — on Salus Cloud or your own. From $25per builder / mo + consumption - Everything in Pro - Runs on Salus Cloud or in your own cloud - Organisation-wide roles and access control - Volume pricing as your rollout widens - SOC 2 Type II & ISO 27001 (audits completing, 2026) - Custom SLAs & dedicated support - Architecture & rollout guidance [Talk to sales](https://salus.cloud/talk-to-sales/) ### BYOC Your cloud account, your IAM, your data residency. Custompriced with your Enterprise plan - A deployment option, added to any Enterprise plan - Runs in your own cloud account - Your data and compute stay under your control - Data residency wherever you need it - Builders from $25/mo, tiering down with volume - You pay your cloud provider for infrastructure [Talk to sales](https://salus.cloud/talk-to-sales/) In practice ## What the meter actually sees. Three real shapes of usage, priced in plain terms — because a pricing model you can predict is the pricing model you can approve. ### A Finance analyst ships an expense tracker 1 builder + one small container She built it with AI in an afternoon; 200 colleagues use it every day. The bill sees one builder and the little it runs. The 200 colleagues: free. ### An engineering team runs 12 production services The builders who shipped + what the services consume Compute, databases and bandwidth meter as used, drawn from your credit balance. Deploys, rollbacks and logs are part of the platform — not line items. ### An agent fixes and redeploys overnight Only the compute its work consumes The agent works with its builder’s access, so it needs no seat of its own. Its builds and scans bill as the compute they burn — same credits as everything else. What you actually pay for ## Builders and what runs. Never the people who use your apps. Two meters, not four. No per-viewer fees and no expiring AI credits — an app your team built getting popular does not add a seat. Builders The people who build Builders and admins in your organisation. $9/mo each on Pro; volume pricing as your rollout widens. Usage What your apps run Compute, databases and bandwidth — prepaid credits on Salus Cloud, or your own provider’s bill when you run BYOC. App users Always free Colleagues and customers who use the apps are never billed. Ship to the whole company without a seat tax. Every plan bills consumption on top: compute, databases and bandwidth. On Salus Cloud that draws from prepaid credits. Enterprise runs on Salus Cloud or in your own cloud — add BYOC when you want your own cloud account, and you pay your provider for the infrastructure. FAQ ## Pricing questions, answered. How is consumption billed? Salus Cloud runs on prepaid credits: start with your $10 starter credit and top up as you go. Credits cover the compute, databases and bandwidth your workloads use. Keep an eye on your balance — top up before it runs out so your apps keep serving. Are the people who use my apps billed? No — never. You pay for builders and for what runs. Everyone who uses what you build is free and does not need a Salus account: colleagues opening an internal tool, customers loading a public site, clients calling your API. This site runs on Salus, publicly, on one builder’s seat. What counts as a builder? A builder or an admin — someone who builds, deploys or administers inside your Salus organisation. Everyone consuming what those people ship is free, however many of them there are. Do AI agents need their own seat? No. An agent works on behalf of a builder, using that builder’s access — so it does not consume a seat of its own. You pay for the compute its work burns, in the same credits as everything else. Is Enterprise the same as running in my own cloud? No — they are separate choices. Enterprise is the governance and support tier, and it runs on Salus Cloud multi-tenant or in your own cloud. BYOC is the deployment option you add when you want it in your own cloud account, quoted on top of your Enterprise plan against your cloud footprint and builder volume. Can I control who can reach what I deploy? Yes. Each deployment can be served publicly or kept internal-only, and you choose the cloud and region an environment runs in. ## Try Salus for free. Start with your $10 credit and ship in minutes. Go to production at $9 per builder, and move into your own cloud when you're ready to scale. [Start free](https://app.salus.cloud)[Book a demo](https://salus.cloud/talk-to-sales/) --- **Source:** https://salus.cloud/developers/ Developers & agents # Salus Cloud developer and agent resources. Everything you need to drive Salus Cloud programmatically — for you, or for the agent working on your behalf. The interface is **MCP**: connect the Salus MCP server and your assistant can create projects, deploy from a repository, provision databases, read logs and metrics, and roll back releases. [Connect the MCP server](https://salus.cloud/docs/cli/)[OpenAPI spec](https://salus.cloud/openapi.json) Predictable URLs ## Resource index Every machine-readable document Salus Cloud publishes, at a stable path. All of them are listed in llms.txt too. | Resource | URL | Format | What it is | | --- | --- | --- | --- | | MCP server descriptor | [/mcp.json](https://salus.cloud/mcp.json) | JSON | MCP registry `server.json` for the Salus MCP server — name, version and how to obtain it. | | MCP tool catalogue | [/mcp-tools.json](https://salus.cloud/mcp-tools.json) | JSON | All 52 tools the server exposes, each with its capability tier, plus the authorization model. Schema at `/mcp-tools.schema.json`. | | OpenAPI specification | [/openapi.json](https://salus.cloud/openapi.json) | OpenAPI 3.1 | The public, unauthenticated discovery surface of salus.cloud. Also served as `/openapi.yaml`. | | Documentation | [/docs/](https://salus.cloud/docs/) | HTML | Quickstart, projects, pipelines, deployments, databases, observability, billing — and the CLI. | | CLI reference | [/docs/cli/](https://salus.cloud/docs/cli/) | HTML | Install the `salus` binary, run it as an MCP server, and choose how much access your assistant gets. | | Authentication | [auth.salus.cloud/realms/salus/.well-known/openid-configuration](https://auth.salus.cloud/realms/salus/.well-known/openid-configuration) | OpenID Connect | OIDC discovery document. Authorization code flow with PKCE (S256); short-lived, refreshable tokens. | | llms.txt | [/llms.txt](https://salus.cloud/llms.txt) | Markdown | What Salus Cloud is, what it does for agents, pricing, and an index of every page on this site. | | llms-full.txt | [/llms-full.txt](https://salus.cloud/llms-full.txt) | Markdown | The complete prose of all 49 pages in one fetch, each chapter stamped with its source URL — the whole site without crawling it. | | Sitemap | [/sitemap-index.xml](https://salus.cloud/sitemap-index.xml) | XML | Every indexable URL on salus.cloud. | [ Install script download.salus.cloud/install.sh Detects your OS and architecture, installs the salus binary to /usr/local/bin. ](https://download.salus.cloud/install.sh)[ Claude Desktop extension download.salus.cloud/salus-mcp.mcpb The MCP server as a one-click .mcpb bundle — no terminal needed. ](https://download.salus.cloud/salus-mcp.mcpb) Two minutes ## Connect the Salus MCP server One binary, one config block. There is no separate login step — the first time your assistant calls a Salus tool, it walks you through browser sign-in. 1 · Install ``` curl -fsSL https://download.salus.cloud/install.sh | bash ``` Prefer not to use a terminal? Install the [Claude Desktop extension](https://download.salus.cloud/salus-mcp.mcpb) instead. 2 · Point your assistant at it ``` { "mcpServers": { "salus": { "command": "/usr/local/bin/salus", "args": ["mcp"] } } } ``` Shown for Claude Code (`.mcp.json`). Cursor, Codex and OpenCode run the same `salus mcp` command — see the [CLI docs](https://salus.cloud/docs/cli/). 52 tools ## Scoped by what it can break Every tool carries a capability tier. You pick how far your assistant reaches — Read-only, Standard, Operator or Full — when you set the server up, and you can narrow it to an explicit list of tools. read 29 View only, no side effects list\_projects, get\_app\_logs, get\_deployment\_metrics write 9 Create or modify — additive, reversible create\_project, create\_database, update\_project operate 9 Act on running workloads deploy\_repo, rollback\_deployment, set\_deployment\_offline destructive 5 Delete — irreversible delete\_project, delete\_database, delete\_space **How access works.** An agent acts on behalf of the person who invoked it, using that person's own access — so anything that person cannot reach, the agent cannot reach either, and the agent needs no seat of its own. Roles are scoped by organisation, space and project. Being explicit, because it matters when you evaluate us: an agent does not hold an identity separate from the human today, so platform records name that person, not the agent. The tier preset above is a guardrail on the machine running the server — it decides which tools that server offers. Platform roles and permissions apply to every call regardless. What can change, and how you'll know ## Versioning, deprecation and rate limits Stated so you can integrate against these URLs without watching them. The same policy is machine-readable in /openapi.json under info.x-versioning, info.x-deprecation and info.x-rate-limits. Additive only, dated, and never silently removed The documents on this page are versioned by date, not by URL path. Paths are stable and new fields may appear without notice; nothing is removed or renamed without first carrying a `Deprecation` header (RFC 9745) and a `Sunset` header (RFC 8594) for at least 90 days, with a `Link rel="successor-version"` pointing at the replacement. Nothing is deprecated today, so those headers are absent — their presence is the signal. There is deliberately no `/v1/` prefix and nothing to negotiate on the way in. To tell one snapshot from another, read the `Salus-Discovery-Version` response header — it carries the same date as `info.version` in the OpenAPI document, so you can detect a change without refetching and diffing. The platform's own HTTP API is separate, versioned in its URL path, and not covered by this policy. No rate limits, and no rate-limit headers Every URL in the resource index is a static file. Nothing is metered, so there are no `RateLimit` headers to read — we don't emit them, because a limit nobody enforces is a number you'd throttle against for no reason. Polling is safe. DDoS protection at the CDN may still refuse abusive volumes; those thresholds aren't published and aren't expressed as rate-limit headers. Prefer caching anyway: `/mcp-tools.json` changes on CLI releases and the rest change on site deploys, not per request. MCP tool calls run against the platform API, which is a different surface with its own limits. Unknown paths return a real 404 Not a 200 with an error page. The body is negotiated from `Accept`: an RFC 9457 `application/problem+json` document with a machine-readable `code` and recovery URLs, markdown, or HTML. URLs here end in a trailing slash; an unslashed path 301s to the slashed form in one hop. What isn't here ## So you don't go looking Three things developers reasonably expect that we don't publish yet. We'd rather you know now than find out mid-integration. No public REST API contract The platform is driven by a versioned HTTP API that the CLI and console use, but it is not publicly specified and carries no compatibility commitment — so it is not documented in `/openapi.json`, which covers the public discovery surface only. Use MCP or the CLI. If you need a supported REST contract, [tell us what you're building](https://salus.cloud/talk-to-sales/). No outbound webhooks There is no webhook subscription API. To follow a build, poll `get_pipeline` after triggering a deploy; for organisation-wide activity, read `list_organization_events`. No sandbox, and no API keys There is no test or sandbox environment — every environment is a real one, so treat a Free-tier deploy as production. And there is no key to generate: authentication is browser-based OAuth with PKCE, driven by the MCP server itself (`auth_login`, then poll `auth_status`). Signing up is self-serve and free, and connecting a repository grants $10 of credit. A connected Git provider is required Salus builds from a clone, so a connected GitHub, GitLab or Azure DevOps repository is needed before a project can be created or deployed. There is no archive-upload or image-only path, and Salus does not create the repository for you. ## Start with read-only. Widen when you trust it. Install the CLI, connect it to your assistant, and give it the narrowest tier that gets the job done. [Read the CLI docs](https://salus.cloud/docs/cli/)[Talk to our team](https://salus.cloud/talk-to-sales/) --- **Source:** https://salus.cloud/docs/ DocumentationIntroduction # Introduction Salus is a developer platform that gives engineering teams a paved road from commit to production. Connect a repository and Salus handles the rest of the software delivery lifecycle for you: it builds your application, runs your tests, scans your code and dependencies for problems, deploys the result to a managed environment, and then gives you the logs, metrics, and controls to run it in production. In platform-engineering terms, Salus is an **internal developer platform (IDP)** delivered as a service. Instead of wiring together a CI server, a container registry, a secrets manager, a deployment tool, a database host, and an observability stack, you get one platform where security and quality checks are built into the path by default — not bolted on afterwards. Note New to Salus? The fastest way to understand it is to [connect a Git provider](https://salus.cloud/docs/getting-started/git-management/) and [create your first project](https://salus.cloud/docs/getting-started/projects/). You’ll have a running deployment in minutes. ## What you can do with Salus - [Ship with automated pipelines](https://salus.cloud/docs/pipelines/pipelines/)Every push runs a DevSecOps pipeline — build, test, static analysis, and vulnerability scanning — before anything reaches production. - [Deploy and scale applications](https://salus.cloud/docs/deployments/deployments/)Configure environments, set resources and scaling, and deploy to managed infrastructure without writing deployment tooling. - [Provision managed databases](https://salus.cloud/docs/deployments/databases/)Create databases with the right resource tier, control network access, and wire connection details straight into your projects. - [Observe what's running](https://salus.cloud/docs/observability/metrics/)Centralized logs and RED metrics (requests, errors, duration) across your deployments, in one place. - [Let Salus Intelligence help](https://salus.cloud/docs/salus-intelligence/)An AI layer that surfaces insights across your pipelines, deployments, and security findings so you spend less time digging. - [Manage your organization](https://salus.cloud/docs/getting-started/organizations-and-teams/)Invite members, manage roles and seats, connect Git providers, and track billing and credits. ## How Salus is organized A few concepts show up everywhere in Salus. Understanding how they nest makes the rest of the documentation easier to follow. - **Organization** — your top-level account. It holds your billing and credits, your connected Git providers, your members and their roles, and your managed databases. Everything else lives inside an organization. - **Workspace** — a grouping of related projects (referred to as a _space_ in some parts of the platform). A new workspace starts with a single environment named **Production**; you can add more — a development or staging environment, say — whenever you need them. - **Project** — a single application, imported from one Git repository. A project owns its build configuration, its pipelines, and its deployments. - **Environment** — an isolated context a project deploys into, with its own runtime variables, secrets, networking, and compute. Environments are what let the same project run safely in development and production without interfering with each other. - **Release configuration** — how a project is set up to deploy into a specific environment: which branch or tag to track, how much CPU and memory to allocate, how many instances to run, which port to expose, and whether it’s reachable on the public internet. Tip Mental model: **Organization → Workspace → Project → Environment.** You connect a repo to create a _project_, and each project gets a _release configuration_ per environment it deploys to. ## The delivery pipeline at a glance When code lands, Salus runs it through a sequence of stages. Each stage produces its own report and logs, and you can require any stage to pass before a deployment is allowed. 1. **Prepare** — fetch your source and set up the build context. 2. **Build** — package your app using Salus buildpacks or your own Dockerfile. 3. **Unit testing** — run your test suite and collect coverage. 4. **Static code analysis** — surface bugs, code smells, and style issues. 5. **Package vulnerability scanning** — check your dependencies for known vulnerabilities. 6. **Deploy** — release the build into the target environment. 7. **Sync** _(Enterprise)_ — propagate the release to configured deployment targets. See [Pipelines](https://salus.cloud/docs/pipelines/pipelines/) for how stages, statuses, and rules work, and [Pipeline Customization](https://salus.cloud/docs/pipelines/pipeline-customization/) for blocking deployments when a check fails. ## Where to go next - **Getting started** — [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/), [Git Management](https://salus.cloud/docs/getting-started/git-management/), [Supported Stacks](https://salus.cloud/docs/getting-started/supported-stacks/), and [Projects](https://salus.cloud/docs/getting-started/projects/). - **Build and ship** — [Pipelines](https://salus.cloud/docs/pipelines/pipelines/), [Builds](https://salus.cloud/docs/pipelines/builds/), [Environment Configurations](https://salus.cloud/docs/deployments/environment-configurations/), and [Deployments](https://salus.cloud/docs/deployments/deployments/). - **Operate** — [Metrics](https://salus.cloud/docs/observability/metrics/) and [Logs](https://salus.cloud/docs/observability/logs/). - **Account** — [Billing Dashboard](https://salus.cloud/docs/account-and-billing/billing-dashboard/) and [Salus Credits](https://salus.cloud/docs/account-and-billing/salus-credits/). --- **Source:** https://salus.cloud/agents/ Agents · MCP-native # Any agent. One governed lane. Your teams already build with agents. Salus is the platform those agents ship to: every operation is an MCP tool an agent can call — deploy, roll back, read logs, provision a database — under the same RBAC, budgets, and audit trail as a human. [Start building](https://app.salus.cloud)[Book a demo](https://salus.cloud/talk-to-sales/) Claude CodeCursorCodexCopilotWindsurfYour own agents Any MCP-capable agent can target Salus. agent@governed-lanezsh How it works ## Connect. Scope. Ship. Three steps from an agent on a laptop to governed deploys in your cloud. 01 ### Connect Point your agent at the Salus MCP server. Every operation on the platform — discover, provision, configure, deploy, operate — is a tool it can call. No glue code, no bespoke integration. 02 ### Scope The agent works with the access of the builder who invoked it — never more. Whatever that person cannot reach, the agent cannot reach, on every call, without anyone configuring a second set of rules. 03 ### Ship The agent builds, deploys, watches the pipeline, reads the logs, and rolls back if it has to — through the same pipeline, gates and scans as a human deploy. Not a sandbox, not a preview: the real thing. The tools ## The whole platform, exposed as MCP tools. Not a read-only API key bolted on after the fact — the operations themselves, callable by any agent, governed on every call. Discover List projects, environments, and services — the agent sees exactly what its role allows, nothing else. Provision Create databases, set environment variables, wire up config — with the same permissions its builder holds. Deploy Ship from a repo to a running, monitored URL, in the cloud and region you chose for that environment. The same build, scan and deploy stages run whether a person or an agent started it. Operate Poll pipelines, stream logs, read metrics and costs, roll back a bad release, take a deployment offline. The full loop. Why IT says yes ## Governance that covers the actor, not just the artifact. Most platforms give agents a read-only key — or no governed way in at all. Salus gives agents a role: permission to ship, boundaries they can't cross, and a record of everything they did. ### Never more than its builder An agent authenticates as the person who invoked it, so it inherits their roles exactly — it cannot reach a project, space or environment they could not reach themselves. ### Isolated workloads Every app an agent ships runs in its own isolated infrastructure with its own credentials, so a mistake stays inside the app it was made in. ### One trail, append-only Agent and human activity land in the same append-only store — written once, never edited or deleted, isolated per tenant. Giving the agent its own identity in that trail, distinct from its human, is work in progress and we will say so plainly. ### An off switch Any deployment can be taken offline on demand — console, CLI or tool call — and any release rolled back. Autonomy with an off switch is autonomy IT can approve. ## Give your agents somewhere governed to ship. Connect an agent, scope its role, and watch it deploy real apps to your cloud — fast, and inside the rules. [Start building](https://app.salus.cloud)[Book a demo](https://salus.cloud/talk-to-sales/) --- **Source:** https://salus.cloud/changelog/ # Salus Changelog — Product Updates & Release Notes Changelog ## What's new in Salus. Product updates, improvements and fixes — as we ship them. [ Changelog #0009 · July 20, 2026 ## Database linking, live activity notifications, and a cleaner dashboard Link a database to a project and get its connection details as read-only environment variables, track your pipelines and databases from a live activity dropdown, and find your way around a reorganised navigation bar. Read the update](https://salus.cloud/changelog/changelog-07202026/)[ Changelog #0008 · July 13, 2026 ## Salus MCP v0.18.0 — rollbacks, security insight, and safer agent deploys The Salus MCP server gains deployment rollback, org-wide security insight, level-aware environment variables, and honest pipeline status — plus hardened login, clearer errors, and a new nightly canary channel. Read the update](https://salus.cloud/changelog/changelog-07132026/)[ Changelog #0007 · July 7, 2026 ## Security visibility, clearer costs, and a smoother platform A new Vulnerability Dashboard and Deployment Frequency panel, honest "completed with warnings" pipeline status, database password rotation, complete billing for deleted databases, and a batch of navigation and reliability fixes. Read the update](https://salus.cloud/changelog/changelog-07072026/)[ Changelog #0006 · June 16, 2026 ## Supply-chain security and tighter login controls Software Bills of Materials generated at deploy time, rootless container builds with a read-only root filesystem, and the ability to lock sign-in to your GitHub organisation. Read the update](https://salus.cloud/changelog/changelog-06162026/)[ Changelog #0005 · June 11, 2026 ## Trusted devices, developer tooling, and reliability upgrades Remembered trusted devices for 2FA, a dedicated CLI and MCP downloads page, smarter command-menu search, better performance monitoring, and a batch of security and reliability improvements. Read the update](https://salus.cloud/changelog/changelog-06112026/)[ Changelog #0004 · May 10, 2026 ## Rollbacks and general platform enhancements One-click deployment rollbacks, a smoother project creation flow, and a faster platform. Read the update](https://salus.cloud/changelog/changelog-05102026/)[ Changelog #0003 · May 5, 2026 ## RBAC on space and project level Provision access at a space or project level! Read the update](https://salus.cloud/changelog/changelog-05052026/)[ Changelog #0002 · April 15, 2026 ## Pipeline visibility and security hardening Instant build-failure emails, more reliable and downloadable pipeline logs, and a round of security hardening. Read the update](https://salus.cloud/changelog/changelog-04152026/)[ Changelog #0001 · March 26, 2026 ## Flexible configuration, smarter automation, and clearer billing Hierarchical environment variables, multi-org accounts, build-minute tracking, smarter pipeline automation, billing upgrades, and Salus Intelligence improvements. Read the update](https://salus.cloud/changelog/changelog-03262026/) --- **Source:** https://salus.cloud/changelog/changelog-03262026/ [← All updates](https://salus.cloud/changelog/) Changelog #0001 · March 26, 2026 # Flexible configuration, smarter automation, and clearer billing configurationpipelinesbillingintelligence This is a big one. This release spans configuration, accounts, billing, pipeline automation, and Salus Intelligence, giving you more control over how your applications are configured, how your team is organised, and how you understand and manage spend. ## Hierarchical environment variables Configuration rarely lives at a single level, and now your environment variables don’t have to either. You can manage variables across four levels, so you can set broad defaults high up and refine them exactly where you need to: - **Organisation** — shared defaults that apply across everything you run. - **Space** — configuration shared by a group of related projects. - **Project** — values specific to a single project. - **Deployment** — settings scoped to an individual deployment. The result is significantly greater flexibility: define something once at the top, and override it only where a particular space, project, or deployment needs something different. ## Multi-organisation support on the free tier Free-tier users can now create and manage multiple organisations from a single account. Whether you’re separating clients, side projects, or teams, you can keep each one cleanly isolated without juggling separate logins. ## Build minutes and usage tracking Build minute consumption is now tracked and measured, giving you real transparency into how your resources are being used. You can see where your build time is going, which makes it far easier to understand utilisation and plan ahead with no surprises. ## Pipeline automation improvements We introduced several deployment workflow enhancements that make your pipelines smarter and less wasteful: - **Auto-cancel stale pipelines** — stuck pipelines are terminated automatically, so they stop consuming compute you don’t need to spend. - **Task-level rules** — pipeline and deployment rules now operate at the task level, giving you more granular control over how automation behaves. - **Workload controls** — enable or disable workloads directly from the UI. Disabling a workload takes it offline without deleting your deployment, so you can pause something and bring it back whenever you’re ready. ## Invoice and billing improvements Billing received a major upgrade, making it more transparent and self-serve: - **Invoice generation** — generate invoices for your account, delivered directly to your inbox. - **Receipt generation** — receive receipts for payments made. - **Improved spend tracking** — a clearer view of what you’re spending and where. - **Usage reporting enhancements** — richer reporting on how your account is being used. ## Salus Intelligence improvements The Intelligence platform received substantial upgrades across the board: - **Improved root cause analysis** — sharper insight into why something went wrong. - **Better repository analysis** — a deeper read of your codebase. - **Faster codebase processing** — quicker turnaround when Intelligence works through your code. - **Enhanced vulnerability remediation** — more capable help fixing security issues. - **More reliable onboarding assistance** — steadier guidance as you get set up. * * * As always, these changes are live now and require no action on your part. We’d love to hear what you think. Your feedback shapes what we build next. --- **Source:** https://salus.cloud/changelog/changelog-04152026/ [← All updates](https://salus.cloud/changelog/) Changelog #0002 · April 15, 2026 # Pipeline visibility and security hardening pipelinesloggingsecurity This release sharpens how you see and secure your pipelines: know the moment a build fails, get to the bottom of issues with more reliable, and now downloadable, logs, and benefit from a round of security hardening across the platform. ## Build failure notifications Salus now emails you the moment a build pipeline fails. Instead of finding out about a broken build the next time you happen to open the dashboard, you hear about it straight away, so you can jump on the fix while the context is still fresh. ### Why this matters - **Respond faster** — catch failures as they happen, not hours later. - **Less babysitting** — you don’t have to sit and watch a pipeline to know how it ended. - **Smoother teamwork** — whoever’s on point gets the signal without someone having to spot the failure and pass it along. ## More reliable log analysis Troubleshooting is only as good as the logs behind it. We’ve made log ingestion and processing more reliable, so the information you need is there when you reach for it. Fewer gaps and more dependable output when you’re working through troubleshooting and root-cause analysis. ## Downloadable pipeline logs You can now download pipeline logs directly from the UI. That makes it easy to dig into a tricky build, hand the full output to a teammate, or keep a copy on file for auditing and record-keeping. No copy-pasting from the browser required. ## Security improvements We shipped several security-focused updates as part of our ongoing hardening work: - **Additional security headers** — stronger defaults at the HTTP layer. - **Authorisation improvements** — tighter control over what authenticated users are allowed to do. - **Dependency vulnerability remediation** — known vulnerabilities in third-party dependencies patched. - **Authentication enhancements** — improvements to how users sign in and are verified. * * * As always, these changes are live now and require no action on your part. We’d love to hear what you think — your feedback shapes what we build next. --- **Source:** https://salus.cloud/changelog/changelog-05052026/ [← All updates](https://salus.cloud/changelog/) Changelog #0003 · May 5, 2026 # RBAC on space and project level securityaccess-controlrbac ## RBAC, now at a space and project level Until today, every member of your Salus organisation had access to every space and project in it. That made onboarding fast, but made the principle of least privilege impossible to apply. Starting in this release, access is scoped — you can grant a teammate the ability to deploy a single project without exposing the rest of your infrastructure. ### What’s new - **Space-level roles** — `Owner`, `Admin`, `Developer`, and `Viewer` per space, independent of organisation membership. - **Project-level roles** — the same role set, scoped to individual projects within a space. ### Why this matters If you’re running production workloads alongside experimental projects, you no longer need to choose between speed and access hygiene. Contractors, ML researchers, and on-call rotations can be granted scoped access to exactly the projects they touch — without exposing the rest of your workloads. ### How to use it From the dashboard: 1. Open the space or project you want to scope access on. 2. Go to **Settings → Members**. 3. Choose **Add member**, pick a role, and Salus will email an invite. ### Migration notes Existing organisation-level roles continue to work — every current member retains the access they had before this release. There is no required action. If you want to tighten access, open **Project Settings → Members** or **Workspace Settings → Members** and provide members with the exact role required per workspace or per project. Anyone removed from a space will lose access to every project in it. --- **Source:** https://salus.cloud/changelog/changelog-05102026/ [← All updates](https://salus.cloud/changelog/) Changelog #0004 · May 10, 2026 # Rollbacks and general platform enhancements deploymentsonboardingperformance This release is about confidence and momentum: recover from a bad deploy in a single click, get new projects off the ground with less friction, and enjoy a platform that simply feels faster. ## Deployment rollback Shipping should never feel like a one-way door. With deployment rollback, you can return a project to a previous deployment state with the click of a button, so when a release doesn’t behave the way you expected, getting back to a known-good version is immediate rather than stressful. ### Why this matters - **Faster recovery** — when something goes wrong, roll back right away instead of scrambling to diagnose and re-deploy under pressure. - **Lower-risk releases** — knowing you can reverse a deployment instantly makes it easier to ship often, and to ship with confidence. - **Less disruption** — your users spend less time on a broken release while you investigate the root cause at your own pace. Rollback turns a stressful incident into a routine, reversible step. That’s exactly what you want when production is on the line. ## A smoother project creation experience We’ve reworked the path from “new account” to “first project” so getting started takes less effort and less guesswork: - **Simpler organisation setup** — fewer steps to stand up your first organisation. - **An improved creation flow** — a clearer, more guided path through creating a project. - **Better onboarding guidance** — helpful pointers along the way, so you always know what comes next. - **Enhanced navigation assistance** — easier movement through the dashboard while you find your footing. Whether it’s your first project or your fiftieth, there’s less friction between an idea and a running deployment. ## Platform performance improvements Under the hood, we shipped a range of performance optimisations that make the platform faster and more responsive across the board. These are behind-the-scenes improvements, so there’s nothing you need to change or configure. You should simply notice a snappier, smoother experience as you move around Salus. * * * As always, these changes are live now and require no action on your part. We’d love to hear what you think. Your feedback shapes what we build next. --- **Source:** https://salus.cloud/changelog/changelog-06112026/ [← All updates](https://salus.cloud/changelog/) Changelog #0005 · June 11, 2026 # Trusted devices, developer tooling, and reliability upgrades securitytoolingreliabilityperformance This release focuses on three things: keeping your account secure without getting in your way, getting developers set up faster, and making the platform steadier and easier to navigate. ## Trusted device authentication Signing in to Salus is now both more secure and more convenient. You can mark a device as trusted during two-factor authentication, so Salus remembers it and stops prompting you for a second factor every time. You keep strong account security, with far less friction on the devices you use every day. ## Salus CLI and MCP downloads Developers can now grab the Salus CLI and MCP tools from a dedicated downloads page. Everything you need to get up and running lives in one place, so setting up your local environment and onboarding new teammates is significantly faster. Working with your AI of choice just got a lot easier. No longer do you need to leave your Claude Code session to deploy; simply use our CLI/MCP to integrate Claude directly into Salus. ## Smarter navigation and search The command menu is more helpful when you’re not sure exactly what you’re looking for. When no matching results are found, it now launches the Conversation Agent automatically, so instead of hitting a dead end you get pointed straight towards an answer. We’ve also smoothed out several navigation flows across the platform, including login handling and homepage redirects. ## Better platform performance monitoring Application performance metrics have been significantly improved, giving your team more accurate insight into the health and reliability of your applications. Better signal means you can trust what you’re seeing and act on it with confidence. ## Security enhancements A number of security improvements landed this month: - **Trusted device authentication** — remember trusted devices during two-factor authentication, as described above. - **Expanded non-root workload support** — broader support for running workloads as a non-root user, which is a safer default. - **Dependency vulnerability remediation** — known vulnerabilities in third-party dependencies patched. - **Infrastructure hardening and security updates** — ongoing hardening across the underlying platform. ## Reliability improvements We also delivered a range of reliability fixes that make day-to-day work smoother: - **Improved login handling** — a more dependable sign-in experience. - **Better deployment pipeline diagnostics** — clearer signal when something in a pipeline needs your attention. - **Enhanced database naming consistency** — more predictable, consistent naming for your databases. - **Improved environment variable onboarding** — a smoother path for setting up environment variables. * * * As always, these changes are live now and require no action on your part. We’d love to hear what you think. Your feedback shapes what we build next. --- **Source:** https://salus.cloud/changelog/changelog-06162026/ [← All updates](https://salus.cloud/changelog/) Changelog #0006 · June 16, 2026 # Supply-chain security and tighter login controls securitydeploymentsaccess-control This release is about knowing exactly what you ship and controlling exactly who gets in. Every deploy now produces a verifiable inventory of what’s inside it, builds run with a safer default, and you can restrict access to the people who belong in your organisation. ## Know what you shipped: deploy-time SBOM generation Every deployment now generates a Software Bill of Materials (SBOM) at deploy time — a complete, verifiable inventory of the components that make up what you shipped. When a new vulnerability surfaces in the wild, you no longer have to guess whether it affects you. You can look at exactly what went out, in which release, and respond with confidence rather than speculation. This is the foundation that security and platform teams need for real supply-chain visibility, and it happens automatically on every deploy — nothing to configure. ## Restrict sign-in to your GitHub organisation You can now require that anyone signing in to Salus is a member of your GitHub organisation, and present a streamlined, GitHub-only login experience to match. Access follows your existing org membership, so people who leave the organisation lose access to Salus at the same time — no separate list to keep in sync, and one less way for stale access to linger. ## Reliability under the hood We also completed an upgrade to the pipeline infrastructure that runs your builds and deployments, moving it onto a current, fully supported foundation. There’s nothing to change on your end — this keeps the platform steady and sets us up to ship pipeline improvements faster. * * * As always, these changes are live now and require no action on your part. We’d love to hear what you think. Your feedback shapes what we build next. --- **Source:** https://salus.cloud/changelog/changelog-07072026/ [← All updates](https://salus.cloud/changelog/) Changelog #0007 · July 7, 2026 # Security visibility, clearer costs, and a smoother platform securityobservabilitybillingreliability This release gives your team more to see and more to trust: clearer visibility into security findings and delivery cadence, billing that leaves nothing out, and a raft of fixes that smooth over the rough edges in everyday workflows. ## Vulnerability Dashboard Security findings across your projects now live in one place. The new Vulnerability Dashboard, built on a dedicated data layer, gives your team a single view of where the risks are so nothing slips through the cracks. We’re rolling it out behind a feature flag for a controlled release — reach out if you’d like it turned on for your organisation. ## Deployment Frequency panel A new Deployment Frequency panel surfaces how often you’re shipping, so you can see your delivery cadence at a glance. It’s a simple, honest signal of momentum — and a useful input when you’re tracking how your team’s flow changes over time. ## Honest pipeline status: completed with warnings Pipelines can now finish with a **“completed with warnings”** status, distinct from an outright failure. Advisory, non-blocking steps that raise a flag no longer make a healthy deploy look broken. You get a truthful picture of what actually happened: what succeeded, what needs a look, and what genuinely failed. Relatedly, when a security scan is configured to block deployment, a **passing** scan now correctly allows the deploy to proceed — passing checks no longer inadvertently skipped deployment when enforcement was on. ## Database password rotation You can now rotate database passwords, so keeping credentials fresh is a routine, self-service step rather than a support request. To make that safer, newly generated passwords are now restricted to characters that are always safe inside a connection string — no more surprises from a stray character breaking your config. ## Complete billing for deleted databases Your billing view now includes databases you’ve since deleted, each clearly marked as **“Deleted.”** Usage that happened before deletion is still accounted for, so your costs reconcile cleanly and there are no mystery gaps in the record. ## Environment variable transparency A new API endpoint exposes the full environment variable hierarchy, making overrides visible across levels. When a value is set in more than one place, you can now see exactly which one wins and where it came from — no more guessing why a variable resolved the way it did. ## Fixes that smooth the everyday We closed out a batch of reliability and usability issues: - **Custom domains now work reliably** — adding and managing custom domains no longer loses your changes, and the network access settings are clearer and easier to use. - **Smoother project creation** — creating a project, selecting a repository, and setting up build configuration now flow through without unexpected errors. - **Easier navigation** — moving between spaces and projects is more dependable, and a new breadcrumb makes it easy to see where you are and jump straight into creating a project. - **Safer instance naming** — underscores are no longer allowed in instance names, closing a silent hostname collision. - **Polished invite and input flows** — the `PillInput` experience is cleaner and the invite deletion dialog is now consistent across the product. We also refreshed the in-product documentation to reflect these latest features. * * * As always, these changes are live now and require no action on your part. We’d love to hear what you think. Your feedback shapes what we build next. --- **Source:** https://salus.cloud/changelog/changelog-07132026/ [← All updates](https://salus.cloud/changelog/) Changelog #0008 · July 13, 2026 # Salus MCP v0.18.0 — rollbacks, security insight, and safer agent deploys mcpagentssecuritytooling Salus MCP v0.18.0 gives your AI agents — and the developers working alongside them — a much richer, safer set of tools for operating on Salus directly from their environment. This release adds real operational muscle (rollbacks, security posture, environment management) and makes the whole surface more honest and harder to trip over. ## New tools and capabilities - **Rollback a deployment** — list previous revisions and roll a deployment back to a known-good one, without leaving your agent or editor (`list_deployment_revisions`, `rollback_deployment`). - **Security insight** — an org-wide activity feed (`list_organization_events`) and per-deployment vulnerability posture (`get_environment_vulnerabilities`), so an agent can answer “what changed?” and “are we exposed?” on the spot. - **Level-aware environment variables** — manage variables across organisation, space, project, and release-config levels, with a merged hierarchy and override view so it’s always clear which value wins and why. - **Rotate database passwords** — keep credentials fresh directly through MCP. - **Sign out** — `auth_logout` revokes the session and clears the local token. ## Truthful pipeline status Advisory, non-blocking stage failures are now distinguishable from real ones. Pipelines report `completedWithWarnings`, and stages and tasks carry an `allowedToFail` flag — so a failed, non-blocking security scan no longer reads as a broken deploy. Your agents get an accurate picture of what actually happened. ## Reliability and clearer errors - **Hardened login** — MCP skips re-login when you’re already authenticated, tolerates concurrent sign-ins without clashing, and only surfaces the manual URL if the browser didn’t open on its own. - **Clear “can’t reach Salus” messaging** — network, proxy, and VPN blocks now produce a plain, actionable message instead of a cryptic failure. - **Clearer tool names and descriptions** — reworked to reduce agent confusion, with read-only and destructive-action safety hints surfaced per tool so agents (and you) know what’s safe before acting. ## Distribution and internals - **Nightly canary channel** — a new pre-release MCP build, wired to production and built continuously from `main`, for teams who want the latest ahead of a stable release. - **MCP core as a standalone package** — the MCP core is now split out from the CLI as `@salus-cloud/mcp-core`. - **Deep links to affected resources** — enterprise events and results now link straight to the resources they created or affected, and user-facing copy has been cleaned up throughout. * * * Update to v0.18.0 to pick these up. As always, we’d love to hear what you think — your feedback shapes what we build next. --- **Source:** https://salus.cloud/changelog/changelog-07202026/ [← All updates](https://salus.cloud/changelog/) Changelog #0009 · July 20, 2026 # Database linking, live activity notifications, and a cleaner dashboard databasesobservabilityusability This release is about connection and clarity: wiring a database into your project without copying secrets around, keeping an eye on what you’ve kicked off, and moving through the platform with less hunting. ## Database linking You can now link a database directly to a project. Once linked, the database’s connection details are surfaced automatically as **read-only environment variables**, so your app can reach its database without you copying credentials by hand or keeping them in sync. To keep things safe, the `SALUS_` prefix is reserved and blocked on your own variables, so a linked database’s details can never collide with — or be shadowed by — something you’ve set. We also polished the linking experience end to end, with refreshed Link Database dialogs that make wiring things up straightforward. ## Live activity notifications A new activity dropdown in the header keeps track of the work you’ve started in your current session — the pipelines you run and the databases you create — with live status as it happens: preparing, building, and deploying for pipelines; provisioning through to active for databases. Each item carries a workspace → project → environment breadcrumb and a quick link straight back to it, so you always know where something is and can jump right to it. It keeps the most recent items and lets you clear out the ones that have finished, so the list stays focused on what’s actually in flight. It’s live in production now. ## Deployment-events dashboard A new deployment-events dashboard surfaces deployment activity in one place, giving your team a clear, at-a-glance view of what’s been shipping. A new Deployment Frequency panel surfaces how often you’re shipping, so you can see your delivery cadence at a glance. It’s a simple, honest signal of momentum — and a useful input when you’re tracking how your team’s flow changes over time. ## Easier to navigate We reorganised the navigation bar into logical groups — workspace, databases, and settings, alongside a dedicated insights group — so the thing you’re looking for is where you’d expect it. We also tidied up the dashboard overview and added a support email and a documentation link to the profile dropdown, so help is never more than a click away. * * * As always, these changes are live now and require no action on your part. We’d love to hear what you think. Your feedback shapes what we build next. --- **Source:** https://salus.cloud/contact/ Contact # Let's get you to production. Tell us about your team and your environment. We'll point you at the right starting point — self-serve, BYOC or self-hosted. [ Start free Free starter credit — ship your first app in minutes. Choose this](https://app.salus.cloud)[ Book a demo See the platform with one of our solutions architects. Choose this](https://salus.cloud/talk-to-sales/)[ Deploy in your cloud BYOC — AWS, GCP, Azure, Huawei or your own private cloud. Choose this](https://salus.cloud/enterprise/) NameWork emailCompanyDeployment modelSalus Cloud (multi-tenant)BYOC (your AWS / GCP / Azure / Huawei)Self-hosted on KubernetesHybrid estateNot sure yetWhat are you trying to ship? SendWe'll reply within one business day. ## Thanks — got it. A solutions architect will reach out shortly. ### Prefer a direct line? For enterprise estates, regulated industries and on-prem. - emailhello@salus.cloud - salessales@salus.cloud - statusstatus.salus.cloud ### In a hurry? Skip the form and start in under five minutes. [Start free](https://app.salus.cloud) --- **Source:** https://salus.cloud/docs/account-and-billing/billing-dashboard/ DocumentationBilling Dashboard Account & Billing # Billing Dashboard The billing dashboard is where you manage your organization’s **plan**, **credit balance**, **payments**, and **usage**. It lives in your organization settings. Note The plans and figures below are a guide to how billing is organized. For current pricing and allowances, check the billing dashboard in the app — it’s the source of truth. ## Plans Salus offers a tier of subscription plans: - **Free** (shown as **Hobby** in the app) — get started at no cost, with unlimited projects and a small amount of starting credit. - **Developer** — for individual developers and small teams, with a monthly build-minute allowance and paid seats. - **Pro** — a larger build-minute allowance for growing teams. - **Enterprise** — custom allowances, additional seats, and dedicated support. Each plan sets allowances such as the number of **build minutes** and **seats** (team members). You can upgrade or change your plan from the dashboard. ## Credit balance Your organization runs on [Salus Credits](https://salus.cloud/docs/account-and-billing/salus-credits/). The dashboard shows your current **balance** and warns you when it’s running **low**, so you can top up before usage is interrupted. ## Transactions The dashboard keeps a history of every **credit** (added) and **debit** (spent) on your account. You can filter and sort it by type, including: - **Consumption** — compute your deployments use. - **Database consumption** — usage by your managed databases. - **Build-minute overage** — build time beyond your plan’s allowance. - **AI** — usage of Salus Intelligence. - **Subscription** — plan charges and renewals. - **Payments** and **complimentary/support credits** — top-ups and credits granted to your account. ## Payments You can pay by **card** or **wallet**, and Salus supports several regional currencies (including NGN, ZAR, KES, GHS, and USD). Manage your payment methods and top up your balance from the dashboard. --- **Source:** https://salus.cloud/docs/account-and-billing/salus-credits/ DocumentationSalus Credits Account & Billing # Salus Credits Salus Credits are the unit that funds usage on the platform. Your organization keeps a credit **balance**, and as your applications run, credits are drawn down against what you use. You manage credits from the [Billing Dashboard](https://salus.cloud/docs/account-and-billing/billing-dashboard/). Note This is a guide to how credits work. For current balances, pricing, and rates, check the billing dashboard in the app. ## What credits pay for Credits are consumed by the resources your organization uses, including: - **Compute** — the CPU and memory your deployments run on. - **Databases** — your managed database instances. - **Build-minute overage** — build time beyond your plan’s included allowance. - **Salus Intelligence** — AI usage. ## How you get credits - **With your plan** — subscriptions include an allowance, and the Free plan comes with a small amount of starting credit. - **Top up** — buy more credits at any time, paying by card or wallet. - **Complimentary and support credits** — credits Salus may grant to your account. ## Keep an eye on your balance Salus flags when your balance is running **low**. Top up before it runs out so your deployments and builds aren’t interrupted. Your full history of credits added and spent is available on the [Billing Dashboard](https://salus.cloud/docs/account-and-billing/billing-dashboard/). --- **Source:** https://salus.cloud/docs/cli/ DocumentationCLI # CLI The Salus CLI is a single binary, `salus`. Its headline feature is exposing Salus to your AI coding tools as an [MCP](https://modelcontextprotocol.io) server, so assistants like Claude Code, Cursor, Codex, OpenCode, and Claude Desktop can work with your projects, deployments, logs, databases, and pipelines on your behalf. ## Install Install the `salus` binary with the one-line installer: ```bash curl -fsSL https://download.salus.cloud/install.sh | bash ``` This installs `salus` to `/usr/local/bin/salus`. Prefer not to use the terminal? Download the **Claude Desktop extension** instead — the `.mcpb` bundle at [https://download.salus.cloud/salus-mcp.mcpb](https://download.salus.cloud/salus-mcp.mcpb) — and install it into Claude Desktop. ## Connect it to your AI tools Run the CLI as an MCP server with the `mcp` subcommand. Point your editor at the `salus` binary and it exposes Salus as a set of tools. For **Claude Code**, add this to `.mcp.json`: ```json { "mcpServers": { "salus": { "command": "/usr/local/bin/salus", "args": ["mcp"] } } } ``` Configuration snippets for **Cursor**, **Codex**, and **OpenCode** are available on the Download page — each runs the same `salus mcp` command. ## Sign in There’s no separate login step. The first time your assistant uses Salus, the MCP server prompts you to sign in — it opens your browser to complete authentication, and gives you a link if the browser can’t open automatically. Your session is reused after that. ## What your assistant can do Once connected, your assistant can act on the platform concepts you already know: [projects](https://salus.cloud/docs/getting-started/projects/), [deployments](https://salus.cloud/docs/deployments/deployments/), [logs](https://salus.cloud/docs/observability/logs/), and [databases](https://salus.cloud/docs/deployments/databases/). You choose how much access it has, from **Read-only** through **Standard**, **Operator**, and **Full** — or a custom selection. Start restrictive and widen access only as you need it, especially for tools that can change or deploy your applications. Note The MCP server is how the CLI connects your editor to Salus — it isn’t a replacement for [Salus Intelligence](https://salus.cloud/docs/salus-intelligence/), the AI layer built into the platform itself. --- **Source:** https://salus.cloud/docs/deployments/access-control/ DocumentationAccess Control Deployments # Access Control Access control on Salus covers two separate questions: **who on the internet can reach your running application**, and **who in your organization can act on your resources**. ## Deployment exposure Each deployment is either public or private, set by the **public network** toggle on its [release configuration](https://salus.cloud/docs/deployments/environment-configurations/#public-network): - **Public** — the service is reachable from the internet on a public URL. Use this for anything users or external systems need to call. - **Private** — the service is only reachable internally, within its workspace. Nothing on the public internet can connect to it. Leave a deployment private unless it genuinely needs to be exposed. See [Deployments](https://salus.cloud/docs/deployments/deployments/) for the domains a public deployment is served on. ## Database network access Managed databases have their own network controls, separate from your app’s exposure — a public-access toggle, a CIDR allow-list, and an allowed-IP list. See [Databases](https://salus.cloud/docs/deployments/databases/#control-network-access). ## Team roles Access to your organization’s resources is governed by **roles**. Each member holds a role, and roles range from full control to read-only: | Role | Typical access | | --- | --- | | **Owner** | Full control of the organization, including members and billing. | | **Maintainer** | Manage workspaces, projects, and configuration. | | **Developer** | Work day to day on projects and deployments. | | **Viewer** | Read-only access. | A fifth role, **Guest**, is assigned automatically rather than chosen — see [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/). Permissions are **scoped** to the level they apply at — organization, workspace, or project — so a member can be given broad access in one workspace and none in another. Managing members and their roles is covered under [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/). --- **Source:** https://salus.cloud/docs/deployments/databases/ DocumentationDatabases Deployments # Databases Salus can provision and run managed **PostgreSQL** databases for you. A database is an organization-level resource: you choose a size, Salus creates the instance, and you wire its connection details into the projects that need it — no separate database host to operate. Each database is provisioned into a specific **environment** (deployment target), so you can run, for example, a development instance and a production instance side by side. ## What you get - A managed **PostgreSQL** instance, with the engine version chosen at creation time. - A private **internal endpoint** that your Salus deployments reach directly, plus an optional **external endpoint** for connecting over the public internet. - **TLS is required** on every connection. - A lifecycle status (for example, _Active_) that reflects the instance’s current state and the last change made to it. ## Provision a database ### Choose a resource tier Each tier fixes the CPU, memory, and starting storage for the instance. Pick the smallest tier that comfortably fits your workload — you can scale up later. | Tier | vCPU | Memory | Storage | | --- | --- | --- | --- | | Micro | 0.1 | 0.6 GiB | 1 GB | | Small | 0.3 | 1.7 GiB | 2 GB | | Standard | 1 | 3.75 GiB | 5 GB | | Large | 2 | 8 GiB | 10 GB | | X-Large | 4 | 16 GiB | 100 GB | | 2X-Large | 8 | 32 GiB | 250 GB | Every tier is billed hourly; the current per-tier price is shown when you select it. See the [Billing Dashboard](https://salus.cloud/docs/account-and-billing/billing-dashboard/) for how usage is charged. ### Name the instance and its admin user - **Instance name** — starts with a letter, 3–30 characters, using lowercase letters, digits, and hyphens (no underscores). - **Admin username** — starts with a letter, 3–30 characters, using letters, digits, and underscores (no hyphens). Choose the target **environment** and the **PostgreSQL version** for the instance as part of creation. ### Save the admin password Heads up The admin password is shown **only once, at creation time.** Salus never displays it again — later views of the database mask it. Copy it immediately and store it as a secret (see below). If you lose it, rotate the password to set a new one. ## Connect a database to a project ### Link it to a project The easiest way to wire a database into an application is to **link** it to a project’s environment. From the database’s **Linked projects**, pick a project and one of its environments, and Salus injects the connection details — including the password — into that project’s [environment variables](https://salus.cloud/docs/deployments/environment-configurations/), so you don’t copy anything by hand. The injected variables are named after the database. For a database called `orders-db`: - `SALUS_DATABASE_ORDERS_DB_CONNECTION_STRING` - `SALUS_DATABASE_ORDERS_DB_HOST` - `SALUS_DATABASE_ORDERS_DB_USERNAME` - `SALUS_DATABASE_ORDERS_DB_PASSWORD` Your app reads these at runtime like any other variable. Note A database can only be linked to an environment in the **same deployment target** as the database. ### Connect manually You can also connect using the database’s own connection details — useful for reaching it from outside Salus. Fetching a database’s details gives you its connection string and endpoints: ```plaintext postgresql://:@/ ``` Connections use the standard PostgreSQL port **5432** and require **TLS**. There are two kinds of endpoint: - **Internal** — a private hostname reachable from your Salus deployments in the same organization. This is the default and needs no public exposure. - **External** — a public hostname (on the internet) that you can enable when you need to reach the database from outside Salus, such as from a local machine or a third-party tool. If you wire the connection string in by hand, store it on the project as an [environment variable](https://salus.cloud/docs/deployments/environment-configurations/) and keep the password as a **secret**. Note Because the password is only available at creation time, it isn’t included when you read a database’s connection string later — the password is masked. Set it yourself from the value you saved. ## Control network access By default a database is private — only its internal endpoint is reachable, and public access is off. When you enable the external endpoint you can restrict who may connect: - **Public access** — the toggle that exposes the external endpoint on the internet. - **CIDR allow-list** — the ranges permitted to connect. - **Allowed IP addresses** — individual addresses permitted to connect. Leave public access off unless something outside Salus genuinely needs to connect, and scope the allow-list as narrowly as you can. ## Resize and upgrade - **Scale CPU and memory** by moving the instance to a larger tier. - **Grow storage** to a larger size. Storage is **grow-only** — it can be increased but never shrunk, so raise it deliberately. - **Upgrade the PostgreSQL version** when you’re ready to move to a newer major version. Heads up Resizing, storage growth, version upgrades, and network changes can briefly restart the instance or affect its availability. Apply them during a maintenance window where you can. --- **Source:** https://salus.cloud/docs/deployments/deployments/ DocumentationDeployments Deployments # Deployments Application deployment within Salus involves a structured process for releasing software updates, changes, or new features to various environments. Salus’ deployment functionality is seamlessly integrated within its CI/CD pipelines. These pipelines automate the steps required for building, testing, and deploying applications, resulting in consistent and repeatable processes. ![](https://salus.cloud/docs-assets/image-6.webp) You can view existing and **active deployments** on the deployments page of each project in your workspaces. ## Deployment Summary Each card on the left-hand panel provides a quick overview of your configured environments and a snapshot of how your most recent or current deployments are performing. **Release Status** - **Release active** means that there are recent releases that have been made into that environment - **No release yet** means, since the day this environment was configured no releases have been made **Domains** You can grab quick links for salus or your own custom domains to easily access your latest deployment. If no custom domains have been configured, the link will be automatically available on the card. **Deployment Info** - Status - Trigger date - Branch or tag deployed to ## Deployment Detail For all environments with **active releases**, you can view details of the deployment such as - Associated pipeline details - Networking information - Automated Deployment status - Assigned Resource information Note You can quickly access application performance metrics related to the existing deployments by clicking on the observability button. ## Deployment history and rollback Each environment keeps a history of its **deployment revisions**, so you can see what was released and when. If a release causes trouble, you can **roll back** to an earlier eligible revision to restore a previous known-good deployment. --- **Source:** https://salus.cloud/docs/deployments/environment-configurations/ DocumentationEnvironment Configurations Deployments # Environment Configurations Before you can deploy a pipeline in Salus, you need to configure an **environment**. Environments allow you to separate **testing**, **staging**, and **production** contexts, each with its own data sources, secrets, runtime settings, and access controls. ## Environments **Environments** in Salus are isolated contexts where pipelines are deployed and executed. Each environment has its own **data connections**, **runtime settings**, **secrets**, and **access controls**, allowing teams to safely test, stage, and run pipelines across different stages of development. Think of environments as containers for running your pipelines under specific conditions, so that what happens in development doesn’t affect production. You can also configure your **deployment targets** on **Salus Enterprise** ⭐ ![](https://salus.cloud/docs-assets/image-8.webp) New environment configuration ## New Environment Configuration ### Select/Create an Environment To configure an environment you need to select from the existing list of environments. Only environments that are not already configured will show up. By default, each workspace is provided with a single environment named **Production**. You can **create a new environment** by clicking on the drop-down and clicking “Add new environment”. Select **deployment target** for Enterprise users. Tip Enterprise users can request additional deployment targets for their organization. ### Select a Deployment Strategy You can either use **branches** or **target tags** as per your preferred deployment strategy. Ensure the available tags or branches are available in the connected Git repository. ### Assign Compute Resources You can assign compute resources for your application by selecting from the list of pre-defined memory and CPU sizes and, min and max number of instances. Tip Need more compute than the largest size available here? Higher compute is available on Salus Enterprise. ### 🎉 Ready for Deployments You can set up additional configurations or choose to default to Salus’ configuration for a quick setup. At this point your environment is ready for deployments. ![](https://salus.cloud/docs-assets/image-9.webp) ## Manage Additional Configurations ### Automated Deployments You can decide if you want your applications to be automatically or manually deployed if a pipeline is run. This is always enabled by default. ## Runtime & Buildtime Variables Manage the environment variables your application needs from each environment’s configuration. Each variable can be available at **runtime** (to your running app), at **build time** (during the build), or both. - **Secrets** — mark sensitive values such as API keys and database passwords as secrets. Salus stores them securely and masks them in the UI. - **Files** — a value can be exposed as an environment variable or mounted as a file, for config your app reads from disk. ![](https://salus.cloud/docs-assets/image-11.webp) Runtime Variables ### Where variables are set Variables can be defined at four levels, and a deployment inherits them all merged together. When the same key is set at more than one level, the level closest to the deployment wins: **Organization → Workspace → Project → Release configuration** — later overrides earlier. So you can set a shared value on the organization and override it for a single environment’s release configuration. Heads up Changes to variables take effect on a deployment only after it’s **redeployed**. ### Example For a Node.js service you might set: | Key | Value | Type | | --- | --- | --- | | `NODE_ENV` | `production` | Variable (runtime) | | `DATABASE_URL` | `postgresql://…` | Secret (runtime) | | `API_BASE_URL` | `https://api.example.com` | Variable (build time) | ## Networking ### Port You can define your port, Salus will always default to `8080` ### Public Network You can enable **Expose application to public**. This allows access to your application over the public internet — anyone with the URL will be able to reach it. See [Access Control](https://salus.cloud/docs/deployments/access-control/) for more on public versus private exposure. ### Domains Whenever an application is exposed to the public, Salus assigns a **free domain** for it. You can also configure a custom domain. ## Danger Zone ### Change your Deployment Strategy You can update your deployment strategy in the Danger Zone. Heads up It is not recommended to switch out branches linked to production-type environments. Do this with caution! ### Delete Configuration You can delete deployment configurations. Careful This will permanently delete the configuration setup and all deployment history for this project. This cannot be undone --- **Source:** https://salus.cloud/docs/getting-started/git-management/ DocumentationGit Management Getting Started # Git Management Salus enables users to connect their preferred Git or Version Control System (VCS) to their organization. Connecting a VCS directly to your Salus organization enables you to quickly import repositories and deploy your applications. Salus supports **GitHub**, **GitLab**, and **Azure DevOps**. To connect or manage a connection, head over to your Git settings in your organization settings. ![](https://salus.cloud/docs-assets/image-17.webp) #### GitHub To connect Github: - Click on the “Connect” button associated with Github. - Configure your new application and allow Salus access to all, or some of your repositories. - Review the permissions granted to Salus. - Click on the “Install & Authorize” button to complete the process. - You will be redirected to Salus with a message confirming the successful connection. - The list of VCS providers will now update to reflect the newly connected status of Github. #### GitLab Click on the “Connect” button associated with Gitlab, you will be redirected to a modal to input required details for the connection. Follow the instructions provided in the input forms to complete connection ![](https://salus.cloud/docs-assets/image-18.webp) Connecting to GitLab #### Azure DevOps Click on the “Connect” button associated with Azure Devops, you will be redirected to a modal to input required details for the connection. Follow the instructions provided in the input forms to complete connection. ![](https://salus.cloud/docs-assets/image-19.webp) --- **Source:** https://salus.cloud/docs/getting-started/organizations-and-teams/ DocumentationOrganizations & Teams Getting Started # Organizations & Teams Your **organization** is your top-level account on Salus. It holds your members and their roles, your connected Git providers, your billing and credits, and your managed databases. Everything else — workspaces, projects, and environments — lives inside it. ## Create an organization Create an organization and give it a name (letters and numbers only). Once it exists, you can invite your team, connect a Git provider, and start creating projects. ## Members and roles Every person in your organization is a **member** with a **role** that determines what they can do. There are four roles you can assign, from full control to read-only: - **Owner** — full control, including members and billing. - **Maintainer** — manage workspaces, projects, and configuration. - **Developer** — work day to day on projects and deployments. - **Viewer** — read-only access. You may also see a fifth, **Guest**. You don’t assign it: Salus adds it automatically when someone accepts an invitation to a single workspace or project, so they hold a place in the organization without any organization-wide access. Roles are **scoped** — a member can have one level of access across the organization and a different level in a specific workspace or project. For the full picture of what roles govern, see [Access Control](https://salus.cloud/docs/deployments/access-control/). ## Invite your team Invite someone by email from your organization settings and assign the role they should have. An invitation moves through a clear set of states — **pending** until they accept, then **accepted**, or **expired** if it lapses (you can also see rejected invites). If the person isn’t a Salus user yet, they’ll be prompted to create an account when they accept. Note Team members occupy **seats**, which depend on your plan. If you need more seats, check your [Billing Dashboard](https://salus.cloud/docs/account-and-billing/billing-dashboard/). ## Connect your Git providers Your organization is where you connect the Git providers your projects import from — GitHub, GitLab, and Azure DevOps. See [Git Management](https://salus.cloud/docs/getting-started/git-management/). ## Billing and credits Your plan, credit balance, payments, and usage are all managed at the organization level. See the [Billing Dashboard](https://salus.cloud/docs/account-and-billing/billing-dashboard/) and [Salus Credits](https://salus.cloud/docs/account-and-billing/salus-credits/). --- **Source:** https://salus.cloud/docs/getting-started/projects/ DocumentationProjects Getting Started # Projects A project is your application, imported from a single Git repository. It owns its build configuration, its pipelines, and its deployments. ### Setup a New Project In your organizations’ workspace, click ‘Add’ button and select ‘New project’ from the drop-down. ### Import your Repository Select the Git provider and the repository you want to setup as a new project. To add or [manage a Git provider](https://salus.cloud/docs/getting-started/git-management/), select the drop-down and select the provider you would like to add, or head over to organizations’ settings to manage the available providers ### Define Project Details Your project name and description are populated automatically from your repository details. You can update them, or swap the workspace or repository you want to set up. ### Define Project Type You can set up two types of project on Salus: 1. **Server-side applications** — web services that run backend code (APIs, server-rendered apps). 2. **Client-side applications** — static sites built into HTML, CSS, and JavaScript. For Node.js projects, you also choose the **Node.js version** your app runs on. See [Supported Stacks](https://salus.cloud/docs/getting-started/supported-stacks/). ### Setup Additional Custom Configurations You can set additional build commands, such as: - Install command - Build command - Output directory - Test command Salus fills in sensible defaults for the framework it detects; see [Buildpacks](https://salus.cloud/docs/pipelines/builds/buildpacks/) for how builds are configured. ### Create your Project Once your project is created successfully, you’ll be redirected to the pipeline landing page. ![](https://salus.cloud/docs-assets/image-24.webp) --- **Source:** https://salus.cloud/docs/getting-started/quickstart/ DocumentationQuickstart Getting Started # Quickstart This quickstart walks you through deploying your first application on Salus. You’ll connect a repository, let Salus build and check it, and end up with a running deployment on a public URL — in minutes. ## Before you begin You’ll need: - A Salus **organization** (if you don’t have one yet, create one first — see [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/)). - A **Git account** on GitHub, GitLab, or Azure DevOps, with a repository you want to deploy. ## Deploy your first app ### Connect your Git provider In your organization settings, connect the Git provider your repository lives on. This lets Salus import repositories and deploy from them. Follow the steps for your provider in [Git Management](https://salus.cloud/docs/getting-started/git-management/). ### Create a project from your repository In a workspace, choose **Add → New project**, then pick your connected provider and the repository to import. Salus fills in the project name and description from the repo. Choose the **project type** — a **server-side application** (an API or server-rendered app) or a **client-side application** (a static site). Salus detects your framework and fills in sensible build settings; you can adjust the build command, install command, output directory, and test command if you need to. See [Projects](https://salus.cloud/docs/getting-started/projects/) and [Supported Stacks](https://salus.cloud/docs/getting-started/supported-stacks/). ### Watch the pipeline run Creating the project kicks off a pipeline. Salus runs your code through its stages — prepare, build, unit testing, static code analysis, package vulnerability scanning, and deploy — each with its own report and logs. Follow it live on the pipeline page. See [Pipelines](https://salus.cloud/docs/pipelines/pipelines/). Note The quality and security stages are informational by default. Later, you can require them to pass before a deployment is allowed — see [Pipeline Customization](https://salus.cloud/docs/pipelines/pipeline-customization/). ### Visit your live app Once the deploy stage completes, your app is running. If you exposed it to the public, Salus gives it a free domain you can open right from the deployment — you now have a live deployment. See [Deployments](https://salus.cloud/docs/deployments/deployments/). ## Where to go next You’ve shipped an app. From here you can: - Add **environment variables and secrets** for configuration — see [Environment Configurations](https://salus.cloud/docs/deployments/environment-configurations/). - Provision a **managed database** and wire it into your project — see [Databases](https://salus.cloud/docs/deployments/databases/). - **Gate deployments** on failing tests, analysis, or vulnerabilities — see [Pipeline Customization](https://salus.cloud/docs/pipelines/pipeline-customization/). - **Invite your team** and set their roles — see [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/). --- **Source:** https://salus.cloud/docs/getting-started/supported-stacks/ DocumentationSupported Stacks Getting Started # Supported Stacks Salus builds most applications with no configuration. When you import a repository, its [buildpacks](https://salus.cloud/docs/pipelines/builds/buildpacks/) detect your framework — React, Vue, Next.js, and other common frameworks — and run the right install and build commands for you. Projects come in two shapes (see [Projects](https://salus.cloud/docs/getting-started/projects/)): - **Server-side applications** — web services that run your backend code, such as APIs and server-rendered apps. - **Client-side applications** — static sites built into HTML, CSS, and JavaScript and served directly. For Node.js projects, you choose the **Node.js version** your app runs on. Match it to the version you develop with locally, and prefer an LTS release for production. ## Need a stack the buildpacks don’t cover? If your application needs a language, version, or toolchain the buildpacks don’t handle, switch the project to a **custom Docker build** and build from your own Dockerfile — that lets you run essentially any stack. See [Custom Docker Builds](https://salus.cloud/docs/pipelines/builds/custom-docker/). --- **Source:** https://salus.cloud/docs/observability/logs/ DocumentationLogs Observability # Logs A centralized hub where you can access and analyze logs from your applications deployed on Salus. Here’s what you can do: 1. Search your logs using keywords to quickly find the information you’re looking for 2. Filter logs based on their severity level (such as Trace, Debug, Information, Error, and Warning) and by date time range 3. See the severity summary showing how many log items there are for each severity level 4. View the log table showing the log details, timestamp, and severity 5. Visualize number of logs for each severity level at 15 minute intervals within the selected time range ![](https://salus.cloud/docs-assets/image-45.webp) Heads up Logs are retained for **30 days**. Entries older than 30 days are no longer available. - **Trace:** the finest level of granularity, providing detailed tracking and visibility into the application’s flow - **Debug:** offers insights primarily for development and troubleshooting - **Information:** general operational entries about the application’s normal behavior - **Warning:** an indication that something unexpected happened, or may happen soon - **Error:** shows that a specific operation failed, causing an exception or an unexpected behavior ## Filtering Through Centralized Logs ### Select Deployment Target (Enterprise only) For Enterprise users, you’ll be required to select a deployment target first before you can filter through workspaces and projects. ### Select a Workspace All users can access granular filters by first selecting a workspace. Only a single workspace can be selected at a time. Once a workspace has been selected, the rest of the filters will be active. ### Select an Environment After selecting a workspace, environments in that workspace will be made available in the filters. To find additional environments, ensure to select the workspace that particular environment belongs to ### Select Projects Once you have selected a workspace and environment, projects that have deployments configured will appear in the filters for further interrogation --- **Source:** https://salus.cloud/docs/observability/metrics/ DocumentationMetrics Observability # Metrics Salus’ centralized metrics view highlights **critical system and application issues** using Request, Error and Duration (**RED**) **metrics**. These metrics surface when something requires immediate attention, such as high error rates, failing services and more. By centralizing these metrics in one place, you can quickly spot and respond to problems without digging through multiple tools or logs. While support for more detailed metrics is coming soon, this focused view helps ensure you’re aware of the most urgent risks affecting your applications in production. ## Accessing your application metrics There are two ways to reach your application’s metrics: 1. Navigate to a project’s deployment page 2. Click on the observability tab, it should redirect you to the specific project’s metrics **OR** 1. Click on the metrics icon on the left-hand navigation panel, select from the list of existing projects in your workspace. ![](https://salus.cloud/docs-assets/image-44.webp) - **Number of Requests per second**: allows for immediate recognition of traffic spikes, aiding in scaling decisions, infrastructure planning, and ensuring optimal user experiences during peak times - **Number of Failed Requests per second**: identification of increases in failed requests can trigger immediate investigations, ensuring swift issue resolution and minimizing disruptions to end users - **Duration of Requests in the 99th, 95th, and 75th Percentile**: you can understand not just the average, but also the outliers in system performance. This allows for targeted optimizations, ensuring a consistently high-quality experience for the vast majority of your users Note Compare and full screen view functionalities coming soon! --- **Source:** https://salus.cloud/docs/pipelines/builds/ DocumentationBuilds Pipelines # Builds Salus can trigger a build in the following ways 1. **Push to Git:** When you connect a Git Provider repository, each commit to a tracked branch triggers a new build and deployment. 2. **Project run pipeline:** Clicking **Run pipeline** in the project also triggers a build ## Run a Pipeline from Salus Running a pipeline on Salus will automatically trigger a build. To run a pipeline, navigate to an existing project and click on **run pipeline**. There are two ways you can run pipelines on Salus by **branch or tag.** ## Build configurations Manage how your project is built under **Build Configurations** in the project settings. Salus builds most projects with its in-house buildpacks and detects sensible defaults automatically; you can override any of the build details or switch to a custom Docker build. ![](https://salus.cloud/docs-assets/screenshot-2025-05-26-at-16-04-44.webp) You can set: - **Install command** — how dependencies are installed (auto-detected from your lockfile if left empty). - **Build command** — the command that produces your build. - **Output directory** — the folder your final build output lands in. - **Test command** — the command that runs your [unit tests](https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/). For more detail, see [Buildpacks](https://salus.cloud/docs/pipelines/builds/buildpacks/) and [Custom Docker Builds](https://salus.cloud/docs/pipelines/builds/custom-docker/). ## Build Logs You can view your build logs by clicking on the log tab and the drop down on the left-hand panel to access the application logs for the build stage --- **Source:** https://salus.cloud/docs/pipelines/builds/buildpacks/ DocumentationBuildpacks Pipelines # Buildpacks Salus buildpacks are the default, in-house builder. Connect your repository and Salus detects your framework (React, Vue, Next.js, and others) and runs the right commands — no build files to write. You tune this under **Build Configurations** in your project settings; see [Builds](https://salus.cloud/docs/pipelines/builds/) for how builds are triggered. Where it helps to be explicit, you can override any of these in Build Configurations: - **Install command** — how dependencies are installed. If you leave it empty, Salus auto-detects it from your lockfile (for example `npm ci`, `yarn install`, `pnpm install`, or `bun install`). - **Build command** — the command that produces your production build. If you leave it empty, no build step runs. - **Output directory** — the folder your build writes its final files to, relative to the project root. Salus serves or packages what it finds there. - **Test command** — the command that runs your test suite during the [unit testing](https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/) stage. Note Salus sets sensible defaults for these based on the framework it detects, so you usually only set them when your project does something non-standard. ## Example build settings Salus detects these for you — the values below are shown for reference: | Framework | Build command | Output directory | | --- | --- | --- | | React (Vite) | `npm run build` | `dist` | | Vue (Vite) | `npm run build` | `dist` | | Create React App | `npm run build` | `build` | | Astro | `npm run build` | `dist` | Server-side apps (for example Express, or Next.js in server mode) run continuously and don’t serve a build-output directory. Set a **test command** such as `npm test` to run your suite in the [unit testing](https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/) stage. ## Need more control? If a buildpack can’t express your build — a specific environment, complex system dependencies, or custom steps — build from your own Dockerfile instead. See [Custom Docker Builds](https://salus.cloud/docs/pipelines/builds/custom-docker/). ## Troubleshooting - **Nothing was built.** An empty **build command** means no build step runs. Set it if your framework needs a build. - **Deploy is missing files / serves the wrong thing.** Check the **output directory** — it must point at the folder your build actually writes to, relative to the project root. - **Wrong runtime version.** Set the correct language version in Build Configurations — see [Supported Stacks](https://salus.cloud/docs/getting-started/supported-stacks/). --- **Source:** https://salus.cloud/docs/pipelines/builds/custom-docker/ DocumentationCustom Docker Builds Pipelines # Custom Docker Builds When you need full control over the build environment — a specific base image, complex system dependencies, or custom steps that [Salus buildpacks](https://salus.cloud/docs/pipelines/builds/buildpacks/) can’t express — build your project from your own **Dockerfile** instead. 1. In **Build Configurations**, enable **Custom Docker builds**. 2. Set the **Dockerfile path**, relative to the project root (for example `Dockerfile` or `docker/Dockerfile`). A leading slash is optional — Salus trims it. The path can’t contain commas or trailing spaces. Salus then builds your image straight from that Dockerfile, giving you complete control over how the app is compiled and packaged. Heads up Docker builds trade speed for flexibility — they generally take longer than a buildpack build. ## Troubleshooting - **Docker build can’t find the Dockerfile.** Confirm the **Dockerfile path** is relative to the project root and free of commas and trailing spaces. --- **Source:** https://salus.cloud/docs/pipelines/pipeline-customization/ DocumentationPipeline Customization Pipelines # Pipeline Customization By default, the quality and security stages **report** their results but don’t stop a deployment. Pipeline rules let you turn them into gates. You manage them in the project’s **Pipeline CI/CD** settings. ## Pipeline Rules Pipeline rules let you **block a deployment when a quality or security check doesn’t pass** — so buggy or vulnerable code can’t reach an environment. Instead of treating the checks as advisory reports, you turn them into gates the build must clear before the deploy stage runs. You can gate on any of the quality and security stages: - **Unit testing** — block if tests fail. See [Unit Testing](https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/). - **Static code analysis** — block if analysis fails. See [Code Analysis](https://salus.cloud/docs/pipelines/quality-and-security/code-analysis/). - **Package vulnerability scanning** — block if vulnerabilities are found. See [Package Vulnerability Scanning](https://salus.cloud/docs/pipelines/quality-and-security/package-vulnerability-scanning/). When a gated stage fails, the pipeline stops before deploying and the run is marked failed, so nothing ships until the underlying issue is fixed. ![](https://salus.cloud/docs-assets/image-26.webp) Recommended Gate on the package vulnerability scanning and unit testing stages, so a build that fails them can’t reach production. --- **Source:** https://salus.cloud/docs/pipelines/pipeline-details/ DocumentationPipeline Details Pipelines # Pipeline Details The **Pipeline Details** page provides a comprehensive view of a specific pipeline within Salus. Use this page to monitor your CI/CD performance, view inputs and outputs and troubleshoot issues. Below is an overview of each section to help you navigate and understand the page effectively. ## Pipeline Summary Page The **Pipeline Summary** provides a concise overview of your pipeline’s configuration, status, and key performance metrics—extracted automatically after each **successful run** to help you monitor health and efficiency at a glance. ![](https://salus.cloud/docs-assets/image-16.webp) **Status:** Overall pipeline status **Pipeline status.** Learn more about pipeline status types [here](https://salus.cloud/docs/pipelines/pipelines/#pipeline-statuses-and-what-they-mean) **Git information** - Commit message - Branch SHA or tag title **Pipeline trigger information** - Pipeline author - Trigger date - [Trigger method](https://salus.cloud/docs/pipelines/builds/) ## Pipeline Metrics ![](https://salus.cloud/docs-assets/image-14.webp) After each successful run, Salus extracts key metrics from the stage reports so you can gauge the health of the run at a glance, without reading through every report by hand. | Metric | Description | | --- | --- | | Issues found (Analysis) | Total number of issues surfaced by static code analysis — bugs, code smells, and style violations. | | Number of Failures (Test) | Failing tests — business logic or functional bugs where the code behaves incorrectly. | | Number of Errors (Test) | Tests that crashed — broken code or tests that couldn't be evaluated. | | Number of Vulnerabilities (Security) | Vulnerabilities found by the package vulnerability scanning stage. | Note An overall code-quality grade for the analysis stage is **coming soon**. ## Pipeline Graph ![](https://salus.cloud/docs-assets/image.webp) A **pipeline graph** is a **visual representation** of the stages and dependencies within a data or automation pipeline. It shows how data or processes **flow from one step to the next**, making it easier to understand structure, identify bottlenecks, and troubleshoot errors. In Salus, a **pipeline graph** serves as a central tool for: - Visualizing **execution flow** - Monitoring **real-time status** of each stage - Exploring **metrics, logs**, and **outputs** in context ### **Nodes (Stages)** Each **node** represents a step in the pipeline. Each node displays - **Stage Name** i.e. Prepare, Build, Test, Analysis, Security and Deploy - **Status Badge i.e.** Success, Pending, Skipped, Error, Cancelled - **Associated Tasks** i.e. Git-clone, Build, Code analysis etc - **Action Buttons** for to navigate you to logs, metrics and deployments where applicable ### **Edges (Connections)** The **lines between nodes** represent **dependencies** or **data flow**: - Linear flow (A → B → C) - Conditional paths (e.g., only continue if A succeeds) such as deploy stage. [_Learn how to set rules for your pipelines_](https://salus.cloud/docs/pipelines/pipeline-customization/#pipeline-rules) - Parallel branches (A splits to B and C simultaneously). Only occurs if pipeline rules have been set Reviewing findings from your pipelines will help you and your team understand, manage and control the quality of your codebase. ![](https://salus.cloud/docs-assets/image-32.webp) ## Understanding your Pipeline Summary ![](https://salus.cloud/docs-assets/image-34.webp) Pipeline summary cards **Duration:** Summarizes the amount of time it takes the pipeline from the build stage to the deploy stage **Analysis:** Summarizes the amount of issues found in code analysis stage and assigns a score to the severity of issues found **Test:** Outputs test results from the unit testing stage and summarizes the number of failures and errors. **Security:** Outlines number of vulnerabilities found in your pipeline Note Pipeline comparative data is **coming soon!** ## **Understanding your Pipeline’s Dependencies** You can inspect stages and dependencies in your pipelines in the playground. Each card displays each stage, its related tasks and their real-time status. ![](https://salus.cloud/docs-assets/image-35.webp) Pipeline dependency From the playground, you can quickly navigate to each tasks logs and reports by clicking on the icons in the cards where applicable. --- **Source:** https://salus.cloud/docs/pipelines/pipeline-logs/ DocumentationPipeline Logs Pipelines # Pipeline Logs Pipeline logs give you detailed visibility into a pipeline run. They’re where you go to **debug** a failure, **audit** what happened, and follow the **step-by-step execution** of each stage. ## Where to find them You can open logs from either the **pipeline list** page or the **pipeline details** page, via the **Logs** tab. Once in the logs view, use the drop-down on the left-hand panel to switch between stages — Prepare, Build, Unit testing, Static code analysis, Package vulnerability scanning, and Deploy each produce their own logs for that run. ![](https://salus.cloud/docs-assets/image-2.webp) Heads up Logs are retained for **30 days** from the pipeline’s trigger date. Logs older than 30 days are no longer available, so download anything you need to keep before it ages out. For logs from your running application (rather than a pipeline run), see [Logs](https://salus.cloud/docs/observability/logs/) under Observability. --- **Source:** https://salus.cloud/docs/pipelines/pipelines/ DocumentationOverview Pipelines # Overview Salus pipelines are the backbone of the DevSecOps platform. They automate the software lifecycle from code integration to deployment, with security and quality checks built into every stage. The pipeline dashboard gives you a centralized, real-time view of all the pipelines for a project, so you can track status, spot bottlenecks, and manage your workflows at a glance. Every pipeline runs through **seven stages:** - Prepare - Build - Unit testing - Static code analysis - Package vulnerability scanning - Deploy - Sync _(Enterprise)_ ![](https://salus.cloud/docs-assets/image-29.webp) For each pipeline run, the dashboard shows: - **Progress status** — the real-time status of the run (see below). - **Duration** — how long the run took from when it was triggered. - **Commit message** — the change being built, from your Git provider. - **Triggered by** — the member who started the run. - **Trigger time** — when it was triggered. - **Trigger method** — automatic (a push to a tracked branch) or manual (running the pipeline from Salus). - **Per-stage status** — status of each stage in the run. - **Logs** — jump to the run’s [logs](https://salus.cloud/docs/pipelines/pipeline-logs/). - **Cancel** — stop a run that’s still in progress. ## Pipeline stage summary Hovering over a pipeline’s stages gives you a high-level summary of how each stage did, so you can decide whether to open the [pipeline details](https://salus.cloud/docs/pipelines/pipeline-details/) for a closer look. ![](https://salus.cloud/docs-assets/image-31.webp) ## Pipeline statuses and what they mean - **Pending** — queued, not started yet. - **Waiting** — no task in the stage is running yet, but at least one is set to run. - **In progress** — at least one task is running. - **Successful** — passed with no warnings. - **Warning** — completed, but with warnings. - **Failed** — at least one task failed. - **Skipped** — the stage was set to skip. - **Canceled** — the run was canceled. --- **Source:** https://salus.cloud/docs/pipelines/quality-and-security/ DocumentationQuality & Security Pipelines # Quality & Security The quality and security stages run inside every pipeline. Each produces its own report and logs, and any of them can be set to gate a deployment. - [Unit Testing](https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/) — run your test suite and collect coverage. - [Code Analysis](https://salus.cloud/docs/pipelines/quality-and-security/code-analysis/) — surface bugs, code smells, and style issues. - [Package Vulnerability Scanning](https://salus.cloud/docs/pipelines/quality-and-security/package-vulnerability-scanning/) — check dependencies for known vulnerabilities. You can require any of these stages to pass before a deployment is allowed — see [Pipeline Customization](https://salus.cloud/docs/pipelines/pipeline-customization/#pipeline-rules). --- **Source:** https://salus.cloud/docs/pipelines/quality-and-security/code-analysis/ DocumentationCode Analysis Pipelines # Code Analysis Code analysis automatically reviews your source for problems — bugs, code smells, and style violations — without manual inspection. Running it as a pipeline stage gives you fast, consistent feedback that improves reliability and keeps technical debt in check as your project grows. ![](https://salus.cloud/docs-assets/image-4.webp) For every pipeline run, the code analysis stage runs automatically and surfaces the issues it finds in your code. You can dig into them in the **pipeline details** page, under the report tab for code analysis. ## Code analysis report The report breaks down the problems detected in your code. It tells you how many **files were covered** and the **total number of issues** found, and for each issue it shows: - **Check name** — the specific rule that was violated. - **Description** — what the issue is. - **Severity** — how serious it is. - **Category** — the kind of issue (for example a bug or a code smell). - **Location** — the file and line number(s) where it was found. - **Remediation effort** — an estimate of the work needed to fix it. Note An overall code-quality grade for this stage is **coming soon**. ## Code analysis logs View the analysis-stage logs by opening the **Logs** tab and selecting the analysis stage from the drop-down on the left-hand panel. Recommended Add a guardrail to your pipeline by [blocking deployments](https://salus.cloud/docs/pipelines/pipeline-customization/#pipeline-rules) when code analysis fails. --- **Source:** https://salus.cloud/docs/pipelines/quality-and-security/package-vulnerability-scanning/ DocumentationPackage Vulnerability Scanning Pipelines # Package Vulnerability Scanning Package vulnerability scanning checks the third-party dependencies your application pulls in against known-vulnerability databases. It runs as a stage in your pipeline, so every build tells you whether the packages you’re shipping have reported security issues — before the build reaches an environment. You’ll find the results on your [pipeline](https://salus.cloud/docs/pipelines/pipeline-details/) under its vulnerability report. ## Severity levels Each finding is rated by severity so you can triage the important ones first: | Severity | Meaning | | --- | --- | | **Critical** | Exploitable, high-impact issues — address immediately. | | **High** | Serious issues that should be fixed promptly. | | **Medium** | Moderate risk; plan a fix. | | **Low** | Minor risk; fix as convenient. | ## What a finding tells you Every finding identifies the vulnerability and the exact dependency it affects: - **Vulnerability ID**, title, and description of the issue. - **Severity** (see above). - **Affected package** — the package name, the version you currently have installed, and the package type (ecosystem) it comes from. - **Fixed versions** — the versions that resolve the vulnerability, so you know what to upgrade to. - **References** — links to the advisory or disclosure for more detail. ## Remediate a finding The fastest fix is usually to upgrade the affected dependency to one of the **fixed versions** listed on the finding. If [Salus Intelligence](https://salus.cloud/docs/salus-intelligence/) is enabled for your organization, it can go further: it reviews the vulnerable dependencies and can open a pull request with the proposed upgrade, so you review and merge instead of patching by hand. ## Block deployments on vulnerabilities You don’t have to rely on people noticing a report. Add a [pipeline rule](https://salus.cloud/docs/pipelines/pipeline-customization/#pipeline-rules) so a build that fails the vulnerability check can’t be deployed — turning the scan into an enforced gate rather than an advisory. Recommended Gate on the vulnerability scanning stage so a build that fails it can’t reach production. ## Track how vulnerabilities change Beyond a single build, Salus tracks how your dependency risk shifts between deployments — which vulnerabilities were newly **introduced**, which were **fixed**, and which were newly **disclosed** against packages you already run. This makes it easy to see whether a release is improving or regressing your security posture. --- **Source:** https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/ DocumentationUnit Testing Pipelines # Unit Testing Unit testing is a cornerstone of code quality and reliability. Salus runs your automated unit tests as a stage in the pipeline: it executes your test suite against the codebase, collects the results, and reports them alongside the rest of the run. ![](https://salus.cloud/docs-assets/image-5.webp) Salus uses the test command you provide to run the suite, then collects and reports the results so they’re part of every build. Careful Unit testing isn’t a substitute for monitoring real-world runs — it complements runtime validation by verifying logic ahead of time. ## Understanding coverage data When you review a unit test report, one key metric is **coverage** — how much of your source code your tests actually exercise. It’s expressed as a percentage: 80% line coverage means 80% of your code lines ran during testing. ### Types of coverage on Salus - **Line coverage** — percentage of individual lines executed by tests. - **Statement coverage** — whether each statement in the code was executed. - **Branch coverage** — percentage of decision points (e.g. `if`/`else`) where all paths are tested. - **Method coverage** — percentage of defined functions or methods called during testing. ## Enable unit testing In your project’s settings — or during project creation — you’ll find a **Test Command** field where you define the command that runs your tests. This is optional: if you leave it empty, Salus runs the default test command for the framework it detects for your language. See [Buildpacks](https://salus.cloud/docs/pipelines/builds/buildpacks/). Note If your project has no tests, this stage is automatically skipped. ## Unit test report Open your [pipeline details](https://salus.cloud/docs/pipelines/pipeline-details/) page and click the **Test** tab for a full breakdown of the run: the number of tests, and how many were **failures** (a test’s assertion failed), **errors** (the test crashed and couldn’t be evaluated), or **skipped**, along with your coverage figures. ![](https://salus.cloud/docs-assets/image-5.webp) Heads up Unit test reports may not be available for every language yet. Where a report isn’t supported, use the logs to review your test results instead. ## Unit test logs View the test-stage logs by opening the **Logs** tab and selecting the test stage from the drop-down on the left-hand panel. Recommended Add a guardrail to your pipeline by [blocking deployments](https://salus.cloud/docs/pipelines/pipeline-customization/#pipeline-rules) when unit tests fail. --- **Source:** https://salus.cloud/docs/salus-intelligence/ DocumentationSalus Intelligence # Salus Intelligence Salus Intelligence is an AI layer built into the platform, available to every organization. It works across your pipelines, deployments, logs, and security findings to explain what’s happening and, where it can, do the work for you — turning a problem you’d normally have to dig into into a summary, a report, or even a ready-to-review fix. You don’t go to a separate place to use it — it shows up in context, right where the work is: on a log, on a vulnerability finding, and while you’re onboarding a project. ## What it can do - **Investigate a log** — point it at an application log and it analyses what went wrong, producing a root-cause summary instead of leaving you to read through raw output. See [Logs](https://salus.cloud/docs/observability/logs/). - **Remediate package vulnerabilities** — it reviews vulnerable dependencies flagged during scanning and proposes the fix, and can open a pull request against your repository so you just review and merge. See [Package Vulnerability Scanning](https://salus.cloud/docs/pipelines/quality-and-security/package-vulnerability-scanning/). - **Help you onboard a project** — when you import a repository, it inspects the code and suggests a starting configuration: the language, build command, port, CPU and memory, whether the project has tests, and where build output lives. It also detects the environment variables your app expects and flags which ones should be stored as [secrets](https://salus.cloud/docs/deployments/environment-configurations/). See [Projects](https://salus.cloud/docs/getting-started/projects/). - **Answer questions** — ask it directly in a conversation when you want context on something in your organization. ## How tasks work Each piece of work Salus Intelligence does is a **task** you can follow to completion. A task moves through clear states — _pending_, _running_, _completed_, or _failed_ (and it can be _paused_ or _cancelled_) — so you always know where it stands. When a task finishes it leaves behind a result you can act on. Depending on the kind of task, that might be: - a **pull request** link, for a proposed fix; - a **root-cause report**, for a log investigation; - a **configuration** or **environment-variable** report, for project onboarding. --- **Source:** https://salus.cloud/engineering/ For engineering teams # Real production. Your cloud. Your stack. Salus is the platform engineering teams run production on — any framework, real containers, deployed into your own AWS, GCP, Azure, or Huawei account. Pipelines, observability, and governance included. Not a sandbox, not someone else's runtime. [Start for free](https://app.salus.cloud)[Book a demo](https://salus.cloud/talk-to-sales/) Running production at Jumia, Yoco, Zedcrest, Yuppiechef, and Piggyvest. The platform ## Everything you'd build yourself. Without building it. Push a repo and get the platform your team would have spent quarters assembling — running in your own cloud, so nothing is trapped in ours. ### Pipelines on push Build, test, security-scan, deploy — from buildpacks or your own Dockerfile. Gate deploys on a failed scan, or don't. Your call. ### Any framework, real containers Go, Python, Node, JVM, Rust — if it builds, it ships. No proprietary runtime, no framework wall, no rebuild to leave. ### Your cloud, your region BYOC into AWS, GCP, Azure, Huawei Cloud or your own private cloud — single-tenant, in the region your regulator expects. ### Observability wired in Logs, request rates, latency percentiles, and deploy history per workload — without standing up a monitoring stack first. ### Databases & scaling Managed Postgres, MySQL, and MariaDB. Replicas, autoscaling, and environment promotion without YAML archaeology. ### Governance you control Roles, append-only audit storage, encrypted secrets, consumption reporting and an off switch for any deployment — set once, inherited by every workload. Agentic engineering ## Agentic engineering, first-class. Your team already ships with Claude Code, Cursor, and their own agents. Every Salus operation is an MCP tool those agents can call — deploy, roll back, read logs, provision a database — with the access of the developer who invoked them, through the same pipeline as a human deploy. ### The platform is an MCP server Agents discover projects, run deploys, poll pipelines, and read runtime logs — no glue code, no bespoke integration. ### Scoped like a teammate Agents get roles, not root. Scoped credentials, audit on every action, and never prod-adjacent keys by accident. ### Ship faster, safely Let an agent handle the deploy loop — build, verify, fix, redeploy — while the guardrails you set hold. ## Not a toy. Production, today. Engineering teams at Jumia, Yoco, Zedcrest, Yuppiechef, Piggyvest, Mukuru, and Apex Networks run real production workloads on Salus — payments, e-commerce, fintech — in their own clouds, in their own regions. And when the rest of the company starts building with AI, they ship onto infrastructure you already trust. You set the policies; business teams and their agents build inside a governed lane on the same platform. When one of their apps earns it, it graduates into engineering ownership — same platform, no rebuild, and you were never the ticket queue. [See the builder track](https://salus.cloud/builders/) ## Make production boring. Free to start, pay for what you run, and it deploys into your cloud — so there's nothing to migrate off later. [Start for free](https://app.salus.cloud)[Book a demo](https://salus.cloud/talk-to-sales/) --- **Source:** https://salus.cloud/legal/ Salus Cloud # Legal The agreements and policies that govern use of Salus Cloud. Each one is published here at a stable URL, and every version is kept at its own address so it stays possible to see exactly what was in force on a given date. | Document | Version | In force | What it covers | | --- | --- | --- | --- | | [Subscription Agreement (EULA)](https://salus.cloud/legal/eula/) | v1.2 | On acceptance | The agreement between Salus and the customer, accepted when a Salus account is created. | | [Privacy Policy](https://salus.cloud/privacy-policy/) | — | 26 August 2026 | How personal data is processed, under ECPA, GDPR and POPI. | ## How versions work Each agreement is served as the exact document that was executed, with its version in the URL — so a record of acceptance can point at the precise text a person agreed to, rather than at whatever the current version happens to say. A new version is published at a new address; existing versions are not edited or replaced. Questions about any of these, or a request for a countersigned copy: [hello@salus.cloud](mailto:hello@salus.cloud). --- **Source:** https://salus.cloud/legal/eula/ [Legal](https://salus.cloud/legal/) · Current version v1.2 · Version 1.2 (09.2026) # Subscription Agreement Also referred to as the End User License Agreement, or EULA. This is the agreement accepted when a Salus account is created. Current version The full text, 17 pages: [salus.cloud/legal/salus-eula-v1.2.pdf](https://salus.cloud/legal/salus-eula-v1.2.pdf) Contracting party Salus Cloud Corporation Governing law Delaware The version number is part of the address. A published file is never edited — a revision is issued at a new address, so a record of acceptance always resolves to the text that was accepted. ## When it takes effect For a self-serve account, the agreement takes effect when you accept it during sign-up. The agreement itself defines the effective date a little more broadly, to cover the ways an enterprise customer might come to be bound; for anyone creating an account on salus.cloud, the acceptance step is the one that applies. It also distinguishes between accepting on your own behalf and accepting on behalf of an organisation, including the case of an individual account created with an employer's email address. If you are accepting for an organisation, the agreement requires that you have authority to bind it. This summary is for orientation only. The linked document is the agreement; where this page and the document differ, the document governs. ## Previous versions Superseded versions stay published. If you accepted one of these, it is the text that applied to you, and it remains available at its original address. - v1.1 · Version 1 (4.09.2023) [salus.cloud/legal/salus-eula-v1.1.pdf](https://salus.cloud/legal/salus-eula-v1.1.pdf) In force until 26 August 2026. Retained because accounts created while it applied accepted this text. ## Related How personal data is processed is covered separately by the [Privacy Policy](https://salus.cloud/privacy-policy/). Platform security practices are described on [Security & Trust](https://salus.cloud/security/). For a countersigned copy or a question about the terms: [hello@salus.cloud](mailto:hello@salus.cloud). --- **Source:** https://salus.cloud/privacy-policy/ Updated: 26 August 2026 # Privacy Policy Salus Cloud Corporation, having its registered office at 8 The Green, Ste R, Kent, Dover, Delaware, United States of America together with all of its subsidiaries ("Salus Cloud Corporation" or "We") would like to be transparent when it comes to processing personal data and privacy of our customers, website visitors, and every individual ("You") whose personal data and information are regulated by legislation such as the US Electronic Communications Privacy Act (ECPA), Protection Of Personal Information Act (POPI) and EU Regulation 2016/679 Of The European Parliament And Of The Council (GDPR) and . To achieve this goal. We are publishing this Privacy Policy with the sole purpose of informing You about following the topics: - Processing of Personal Data - General Rules - Data Confidentiality - Data Subject's Rights - Cookies ## Processing of Personal Data All services incorporated in this website and other websites under the control of Salus Cloud Corporation are governed by this Privacy Policy, including those that are governed by specific Terms of Use with data processing rules. Generally, You may use our websites for information purposes without giving personal information and informing Salus Cloud Corporation who you are. On the other hand, some of our services need to collect more information: - Salus Cloud Corporation may collect personal information for the purposes of direct communication with You in order to respond to your questions and fulfill your requests. If You send us product orders, service requirements, or other requests or if you upload any materials to our website, we may have to contact you in order to gain additional information necessary for processing or to fulfill your order, request or requirement. For this purpose, as well as for the purpose of requested performance of services, we need to process your details provided via web forms, email or applications. - If You are an End User of our products or services, the processing of your data is covered by the specific End User License Agreement or Terms of Use and Privacy Policy related to that product or service. - If You agree with processing of your data for the purposes of marketing communication, We may use your details to administer marketing communication until You withdraw your consent. - Contact information and data contained in your support requests are required for service of technical or other support nature provided by Salus Cloud Corporation. Based on the channel You choose to contact us, We may collect your email address, phone number, product details and description of your support case. You may be asked to provide us with other information to facilitate service of support such as generated log files or dumps. The data from support may only be used for the provision of support service and for enhancing customer experience while providing support. - Customer feedback, answer or request, may be provided by You via our web forms. For the purpose of follow-up, your contact details including email address or other data may be requested based on the nature or purpose of our communication. Data storage periods may differ based on the nature or purpose of communication explicitly in compliance with this Privacy Policy. - Salus Cloud Corporation may collect information about your computer using cookies or similar methods (see cookie policy below). Most of this is statistical data about browsing actions and patterns. Some of it is not: where you go on to create a Salus Cloud account, our product analytics links your earlier browsing on this website to that account, and website sessions are recorded as described under “Which analytics providers do we use?” below. These help us to improve our site and to deliver a better and more personalized service. You may refuse to accept cookies by activating the setting on your browser which allows you to refuse the setting of cookies. However, if you select this setting you may be unable to access certain parts of the website. Unless you have adjusted your browser setting so that it will refuse cookies, our system will issue cookies when you log on to our site. - We are doing our best while helping you to enjoy safer technology. Your input is very valuable for us and there are various channels available to provide us with samples of malicious or suspicious software. Samples and its metadata will be processed and stored based on public interest as well as legitimate interest of Salus Cloud Corporation, which is cybersecurity. ## General Rules There are only a few legal bases for data processing which We use according to the ECPA, GDPR and POPI legislative frameworks. Our activities are mainly covered by: - Contractual necessity is applicable when it comes to our products and services provided under End User License Agreements or Terms of Use. - Legitimate interest or even public interest concerning cybersecurity entitles us to collect samples and service data for analysis, to provide You with even better protection, support, and experience We can offer. Even marketing is recognized by GDPR and POPI as a legitimate interest, therefore we rely on this concept when it comes to cookies used by our websites and communication with our customers. - Consent, if required by legislation. - Compliance with a legal obligation e.g. stipulating requirements for electronic communication, invoicing, or billing. The goal of this Privacy Policy is to provide a general overview of the legal basis and data processing principles of Salus Cloud Corporation. If You are looking for more information concerning data collection facilitated by a particular Salus Cloud Corporation product or service, visit our dedicated websites. ## Data Confidentiality Salus Cloud Corporation operates worldwide. Based on your location and service you choose to use, Salus Cloud Corporation might be required to transfer your data to a country that is not covered by ECPA, GDPR or POPI. Even in such cases, every transfer of information is subject to regulation of data protection legislation and takes place only if required. It is our intention to prevent data from being stored longer than necessary while providing Salus Cloud Corporation products and services. Salus Cloud Corporation implements appropriate technical and organizational measures to ensure a level of security that is appropriate to potential risks. We are doing our best to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services. However, in case of a data breach resulting in a risk to your rights and freedoms, We are ready to notify the supervisory authority as well as the data subjects. ## Data Subject's Rights Salus Cloud Corporation is subject to the regulation of US Laws and We consider ourselves bound by data protection legislation binding member states of European Union in addition. Every Data subject is therefore entitled to the following rights: - Right to request access to your personal data from Salus Cloud Corporation, - Right to rectification of your personal data if inaccurate (You also have the right to have incomplete personal data amended), - Right to request erasure of your personal data, - Right to request restriction processing of your personal data, - Right to object to processing as well as - Right to data portability. We believe that all information we process is valuable and necessary for legitimate purposes while providing services and products to our customers, and worth protecting with the highest priority. If You would like to exercise your right as a data subject or You have a question concerning personal data protection or protection of privacy, send us a message at: [hello@salus.cloud](mailto:hello@salus.cloud) ## Cookie Policy In this policy we use the term "cookies" to refer to cookies and other similar technologies covered by the EU Directive on privacy in electronic communications. ### What is a cookie? A cookie is a small piece of data that a website asks your browser to store on your computer or mobile device. The cookie allows the website to "remember" your actions or preferences over time. Most Internet browsers support cookies; however, users can set their browsers to decline certain types of cookies or specific cookies. Further, users can delete cookies at any time. ### Why do we use cookies? We use cookies to learn how you interact with our content and to improve your experience when visiting our website(s). For example, some cookies remember your language or preferences so that you do not have to repeatedly make these choices when you visit one of our websites. Additionally, cookies allow us to serve you specific content, such as videos on our website(s). ### What types of cookies do we use? #### First-Party and Third-Party Cookies We use both first-party and third-party cookies on our website. First-party cookies are cookies issued from Salus Cloud Corporation' domain that are generally used to identify language and location preferences or render basic site functionality. Third-party cookies belong to and are managed by other parties, such as Salus Cloud Corporation' business partners or service providers. These cookies may be required to render certain forms, such as the submission of a job application, or to allow for some advertising outside of the Salus Cloud Corporation website. #### Session Cookies Session cookies are temporary cookies that are used to remember you during the course of your visit to the website, and they expire when you close the web browser. #### Persistent Cookies Persistent cookies are used to remember your preferences within the website and remain on your desktop or mobile device even after you close your browser or restart your computer. We use these cookies to analyse user behavior to establish visit patterns so that we can improve our website functionality for you and others who visit our website(s). These cookies also allow us to serve you with targeted advertising and measure the effectiveness of our site functionality and advertising. ### Which analytics providers do we use? We name our analytics providers rather than describing them generically, because we think you should be able to check them: - **Google Analytics 4** — aggregate traffic measurement: which pages are visited, from where, and on what device. - **PostHog** — product analytics, hosted in the European Union. We use it to understand how people move from this website into the Salus product, so we can find and fix the places they get stuck. Requests are served through our own domain rather than sent to PostHog by your browser. We pass your IP address on to PostHog, which uses it to derive an approximate location; it is not used to identify you personally. **Session recording.** PostHog also records anonymised playback of website sessions — pages viewed, scrolling, and clicks — so we can see where our own site is confusing. Text you type into form fields is masked before it leaves your browser and is never recorded. We do not record sessions inside customer environments in the Salus product console. **Do Not Track.** If your browser sends a Do Not Track signal, PostHog analytics and session recording are disabled for your visit. ### How do I reject and delete cookies? You can change your preferences for Salus Cloud Corporation websites and/or the websites of any third party suppliers by changing your browser settings. Please note that most browsers automatically accept cookies. Therefore, if you do not wish cookies to be used, you may need to actively delete or block the cookies. If you reject the use of cookies, you will still be able to visit our websites but some of the functions may not work correctly. You may also visit [www.allaboutcookies.org](https://www.allaboutcookies.org) for details on how to delete or reject cookies and for further information on cookies generally. By using our website without deleting or rejecting some or all cookies, you agree that we can place those cookies that you have not deleted or rejected on your device. --- **Source:** https://salus.cloud/security/ Security & Trust # The lane IT can trust. Salus exists so security can say "yes" to AI without losing control. Here's how the lane stays governed — and where our compliance program stands. [Talk to our team](https://salus.cloud/talk-to-sales/) Compliance ## Where our program stands today. We're straight about status: our audits are in their final stages, not yet complete. Here's exactly where things are. ### SOC 2 Type II In progress Audit completing — report expected August 2026 ### ISO 27001 In progress Audit completing — certification expected August 2026 ### Penetration testing In progress Independent third-party tests via our compliance program · reports under NDA SOC 2 Type II and ISO 27001 audits are both in their final stages, with reports expected in August 2026. Compliance is monitored continuously in Vanta, and penetration testing is performed by independent third parties. We'll publish reports and certificates here as they're issued — and share current documentation under NDA in the meantime. Platform security ## Governed by default. For humans and agents. The controls that let you hand a lane to every team and every agent without losing the plot — set once, inherited by every app. ### Role-based access control Scope what every person can deploy, reach and change, at organisation, space and project level. An agent acts with its builder’s access, so it inherits those bounds and can never exceed them. ### Encrypted secrets Secrets encrypted at rest and in transit, injected at runtime — never stored in code or logs. ### Isolation & controls Each workload runs isolated, with its own credentials and network boundary, so what one app can reach is bounded before it runs. ### Audit & observability Audit events are written append-only — never edited or deleted — isolated per tenant, each recording the actor and the time. Any deployment can be pulled offline instantly. Shared responsibility ## Who owns what — in plain terms. The question every security questionnaire asks first, answered before you ask it. You own - Your cloud account and IAM (Enterprise/BYOC) - Your data and your databases - Your policies — who may build, deploy, and promote Salus operates - The platform: builds, pipelines, runtime, upgrades - The governance controls: roles, isolation, audit storage, an off switch - Monitoring, patching, and vulnerability management You both see - The full audit trail — every human and agent action - Observability: logs, metrics, costs per workload - Compliance documentation, shared under NDA today ## Your data never leaves your cloud. Salus Enterprise runs single-tenant inside your own AWS, GCP, Azure, or Huawei account (BYOC). Apps, data, and secrets stay within your perimeter and your compliance boundary — in whatever region your obligations require, from the US to the EU to Africa. Residency isn't a feature tier; it's a consequence of the architecture. The governed lane sits alongside production — never inside it. ## Need our security documentation? We'll walk your security team through the architecture, share our controls and current audit status, and provide documentation under NDA. No pitch deck. [Talk to our security team](https://salus.cloud/talk-to-sales/)[Deploy in your cloud](https://salus.cloud/enterprise/) --- **Source:** https://salus.cloud/talk-to-sales/ Technical evaluation # Evaluate Salus for your teams and their agents. The board wants everyone building with AI; security can't let them ship it. This session shows how the governed lane works in your own cloud — and whether it's the right fit. This is a technical evaluation, not a general infrastructure consultation. ## What the session covers - How the governed lane fits alongside your production - How RBAC and policy work for both teams and agents - What running it in your own cloud (BYOC) looks like - Whether it's the right fit for your org For IT, security, and platform leaders giving citizen developers and agents a governed place to ship. 30-minute session Live technical walkthrough Specific to your stack Trusted in production by ![Zedcrest logo](https://salus.cloud/assets/logos/zedcrest.svg)![Yuppiechef logo](https://salus.cloud/assets/logos/yuppiechef.svg)![Apex Networks logo](https://salus.cloud/assets/logos/apex.svg) ## Book your evaluation Fill in your details and we'll reach out within one business day.