# 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 58 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, on Salus Cloud or your own](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/) - [Run across regions and clouds, from one organisation — Salus Changelog](https://salus.cloud/changelog/changelog-08282026/) - [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/) - [Access Control — Salus Docs](https://salus.cloud/docs/deployments/access-control/) - [Databases — Salus Docs](https://salus.cloud/docs/deployments/databases/) - [Connect a Database — Salus Docs](https://salus.cloud/docs/deployments/databases/connect/) - [Manage a Database — Salus Docs](https://salus.cloud/docs/deployments/databases/manage/) - [Provision a Database — Salus Docs](https://salus.cloud/docs/deployments/databases/provisioning/) - [Deployments — Salus Docs](https://salus.cloud/docs/deployments/deployments/) - [Environment Configurations — Salus Docs](https://salus.cloud/docs/deployments/environment-configurations/) - [Deployment History & Rollback — Salus Docs](https://salus.cloud/docs/deployments/revisions/) - [FAQs — Salus Docs](https://salus.cloud/docs/faqs/) - [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/) - [MCP — Salus Docs](https://salus.cloud/docs/mcp/) - [MCP: Getting Started — Salus Docs](https://salus.cloud/docs/mcp/getting-started/) - [MCP: Use Cases & Prompts — Salus Docs](https://salus.cloud/docs/mcp/use-cases/) - [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/) - [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/) - [Terms of Use — Salus Cloud](https://salus.cloud/legal/terms-of-use/) - [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/register)[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) Built something with AI? ## 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 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. Both changes went through your access, under IT’s rules — on record as you. rollback ✓audited claude-code · Salus MCPzsh 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 · recorded as the human 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. Usage is metered per app and per builder, drawn from one prepaid balance. 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 toward consumption. Everything you need to get something real running. ](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/register)[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/register)[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 - 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/register)[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, managed databases, logs and costs. Any framework, no waiting on anyone. [Start free](https://app.salus.cloud/register)[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. Both changes went through your access, under IT’s rules — on record as you. rollback ✓audited API payments-api live p99 24ms · 3 regions Job model-train-a100 scaling cron · nightly Worker ingest-worker building queue 142 Web dashboard-pr-482 live staging MCP ## Your agent already knows how to drive it. Every operation on Salus is an MCP tool your assistant can call — with your access, under IT's guardrails. The salus CLI signs you in and starts the server; everything else happens in the conversation. `deploy_repo` Build, scan and roll out a repository in one call. `get_app_logs` Read a running app's logs, by workload. `get_deployment_metrics` CPU, memory and traffic for a deployment. `create_database` Provision a managed database and link it to the project. `rollback_deployment` Put the last good revision back. `set_deployment_offline` Take a deployment offline instantly — the off switch. 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. ### Managed databases Provision a database alongside the app and link it in one step — no separate vendor, no extra bill. ### Logs, traces and metrics Built-in observability — no extra agent, no extra integration to wire up. ### Roll back in one step Every deploy keeps its revision. If the new one misbehaves, put the last good one back — no rebuild. ### 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 — you will need your code in a GitHub, GitLab or Azure DevOps repository. [Start free](https://app.salus.cloud/register)[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 our cloud or yours. 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 under your rules. Run it on dedicated Salus Cloud infrastructure, or inside your own cloud account. 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 From $25 Per builder / month, plus consumption What Enterprise is ## A plan, not a place. Enterprise is the entitlement tier — governance, isolation, support and contract terms. Where it runs is a separate decision, and not one you have to make up front. The plan From $25 per builder / month Plus consumption, like every tier. You pay for builders and admins — everyone who uses what they ship is free and needs no Salus account. [See what is included ](https://salus.cloud/pricing/) Where it runs Your choice, and only on this tier Run on the managed multi-tenant Salus Cloud environment, or deploy into a dedicated, isolated target inside infrastructure you own. Free and Pro do not get that choice — it is what the Enterprise tier unlocks. BYOC Priced per cluster, on top Your own public cloud account, private cloud or on-premise. BYOC is added to an Enterprise plan, never bought instead of one — so you can start on Salus Cloud and move when your compliance posture asks, without changing tier. Deployment models ## Run Salus where your business needs it. The same control plane runs on Salus Cloud, on Salus hardware, or inside infrastructure you own — without forking the developer experience. Salus CloudSalus HardwareBYOC 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, metered per deployment 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 · private · on-prem ### Bring Your Own Cloud A dedicated, isolated target environment inside infrastructure you own — your AWS, GCP, Azure or Huawei account, your private cloud, or your own on-premise Kubernetes. The control plane is ours; the data plane is yours. Available on the Enterprise tier, and you can run development in Salus Cloud and production in your own under the same control plane. - Your VPC, your IAM, your data residency - Public cloud, private cloud or on-premise - Air-gapped where required 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. An agent acting for someone is recorded as that person — agents do not yet hold their own identity in the trail. 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% in approved regions every app in a cloud and region IT allowed illustrative figures · roles, gates and region selection applied by the platform, not by each team BYOC architecture · an option on Enterprise ## Our control plane. Your data plane. Run Salus-managed workloads inside infrastructure you own — your AWS, GCP, Azure or Huawei account, your private cloud, or your own on-premise Kubernetes. Salus orchestrates; your cloud holds the data, identity and network. Nothing leaves your perimeter. Quoted per cluster, on top of your Enterprise plan. - Workloads run in your VPC, under your IAM - Data residency stays in your region - Customer-controlled certificates and KMS - Public cloud, private cloud or on-premise 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/ 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 Shared hosting Start building, on us. Everything you need to get something real running. $0\+ consumption - Up to 5 builders Soon - $10 starter credit toward consumption — no card needed - Deploy from a connected GitHub, GitLab or Azure DevOps repo — any framework, real containers - One region for your organisation - One build at a time Soon - 7 days of logs and metrics - Docs and community support [Start for free](https://app.salus.cloud/register) ### Pro Most teams Shared hosting Production apps, unlimited builders, more than one region. $9per builder / mo + consumption - Everything in Free - Unlimited builders - Multiple regions per organisation - Concurrent builds Soon - Custom domains - Package vulnerability reports - 30 days of log retention - Roles and access control across org, spaces and projects - Audit log Soon - Serve publicly or keep it internal-only - Managed databases, provisioned with the app - SSO and business-hours support [Start building](https://app.salus.cloud/register) ### Enterprise Salus Cloud or your own Governance, support and contract terms — and the choice of where your workloads run. From $25per builder / mo + consumption - Everything in Pro - Choose multi-tenant Salus Cloud, or a dedicated isolated target in your own cloud - Full audit log, 180-day retention Soon - Organisation-level environment variables and central config Soon - Priority build lanes Soon - Invoiced billing, in arrears Soon - Dedicated account manager and custom SLA - SOC 2 Type II & ISO 27001 (audits completing, 2026) - Volume pricing as your rollout widens - BYOC — your own cloud, private cloud or on-premise, priced per cluster [Talk to sales](https://salus.cloud/talk-to-sales/) ### BYOC Your own cloud Added to an Enterprise plan, never bought instead of one. Customper cluster, on top of Enterprise - Everything in Enterprise - Your own AWS, GCP, Azure or Huawei account, private cloud, or on-premise - A dedicated, isolated target environment in the regions you allow - Your IAM, your network boundary, your data residency - You pay your cloud provider directly for infrastructure - Start on Salus Cloud and move when compliance asks you to [Talk to sales](https://salus.cloud/talk-to-sales/) Everything unmarked is available today. Soon marks a capability that is on our roadmap and not yet available. We would rather show you where we are going than let you find out later. Every plan is + consumption ## Two meters, not four: the builders you have, and what your apps run. Seats are the predictable part. Consumption is the part that scales with success — so here is exactly what it is, before you commit to anything. What meters Compute, memory, storage, bandwidth, CDN, load balancing and managed databases — measured against what your workloads actually use, per deployment. How you pay On Salus Cloud, consumption draws from prepaid credits — top up as you go. Enterprise can be invoiced in arrears instead. On BYOC, your cloud provider bills you directly for infrastructure. What never meters The people who use what you build. Colleagues opening an internal tool, customers loading a public site, clients calling your API — free, and no Salus account needed. An option on Enterprise, not a separate tier ## How BYOC fits. Most teams do not need this on day one, and the ones that do usually know already. BYOC is not a cheaper or bigger Enterprise — it is the question of whose cloud account the platform runs in, answered separately from what you are entitled to. 1 You buy Enterprise for the governance, isolation, support and contract terms — priced per builder, the same either way. 2 You add BYOC per cluster for the infrastructure it all runs inside — your public cloud account, your private cloud, or on-premise. Quoted on top of your Enterprise plan, not instead of it. 3 You can move later start on Salus Cloud today and bring it into your own cloud when your compliance posture asks — same platform, same deploys, no change of plan. [Talk to sales about BYOC](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. 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. Enterprise plans can be invoiced in arrears instead. 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 acts on behalf of the builder who invoked it, as a delegate using that builder’s access — so it never consumes a seat of its own. You pay for the compute its work burns, in the same credits as everything else. The individual grants their agent autonomy; the organisation sets the bounds of what any agent can reach. Where do my workloads actually run? Free and Pro run on Salus Cloud’s shared, multi-tenant infrastructure — your containers, isolated from other tenants, on capacity we operate. Enterprise gets a choice: stay on that managed multi-tenant environment, or deploy into a dedicated, isolated target inside infrastructure you own. That second option is BYOC, and it is only available on Enterprise. Is Enterprise the same as running in my own cloud? No — they are separate choices. Enterprise is the tier: governance, support and contract terms. BYOC is where you choose to run it — a dedicated, isolated target in your own public cloud account, private cloud or on-premise — quoted per cluster on top of your Enterprise plan. You need Enterprise to have the choice at all, and you can start on Salus Cloud and move later. 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/register)[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/mcp/)[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. | | MCP reference | [/docs/mcp/](https://salus.cloud/docs/mcp/) | 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 [MCP docs](https://salus.cloud/docs/mcp/). 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 MCP docs](https://salus.cloud/docs/mcp/)[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 dependencies for vulnerabilities, 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, 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. **Package vulnerability scanning** — check your dependencies for known vulnerabilities. 5. **Deploy** — release the build into the target environment. 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. Today that trail records the person whose access the agent used, not the agent itself. [Start building](https://app.salus.cloud/register)[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/register)[Book a demo](https://salus.cloud/talk-to-sales/) --- **Source:** https://salus.cloud/changelog/ Changelog # What's new in Salus. Product updates, improvements and fixes — as we ship them. [ Changelog #0010 · August 28, 2026 ## Run across regions and clouds, from one organisation One organisation can now span multiple clouds and regions at once, with each environment choosing its own — plus a real region catalogue across Africa, Europe and the Americas, and the ability to delete environments you no longer need. Read the update](https://salus.cloud/changelog/changelog-08282026/)[ 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/changelog/changelog-08282026/ [← All updates](https://salus.cloud/changelog/) Changelog #0010 · August 28, 2026 # Run across regions and clouds, from one organisation multi-regiondata-residencyenvironments This release is about running where you need to run. A single organisation can now stretch across several clouds and regions at once, with every environment picking its own — so where your data lives becomes a setting, not a migration. ## Several regions, one organisation Your environments no longer have to share a single home. Staging in Belgium and production in Cape Town is now an ordinary setup rather than a special deployment — each environment chooses its own cloud and region, all under one organisation. You get to place workloads where they belong, whether that’s for latency, for data residency, or simply because that’s where a particular team operates. ## A real region catalogue Region selection is backed by a genuine catalogue of targets across **GCP, AWS and Huawei**, spanning **Africa, Europe and the Americas** — each one clearly labelled with its continent and country, so there’s no guessing what “eu-west-3” actually means. Admins decide which regions your organisation is allowed to use and set the default, so builders get a curated, compliant set of choices rather than a wall of cryptic codes. This is what “your cloud” looks like in practice: residency and placement wherever you need them, chosen deliberately, not dictated by the platform. ## Data stays where you put it When you create an environment in a region, that choice is authoritative. The cluster, ingress, domain, database placement — and the cost — all resolve from the region the environment was created in. There’s no hidden fan-out to somewhere else: what you selected is where things run and where your data rests, end to end. ## Delete environments you no longer need You can now delete environments directly. When a preview, a spike, or an old staging setup has served its purpose, you can clean it up yourself instead of leaving it lingering — keeping your organisation tidy and your footprint intentional. * * * 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/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. ## 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/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 control, separate from your app’s exposure — a public-access toggle that enables the database’s external endpoint. See [Connect a Database](https://salus.cloud/docs/deployments/databases/connect/). ## 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. A fifth role, **Guest**, is assigned automatically rather than chosen — see [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/). ### What each organization role can do | | Owner | Maintainer | Developer | Viewer | | --- | --- | --- | --- | --- | | View projects, pipelines, deployments, logs, metrics, and vulnerability findings | ✓ | ✓ | ✓ | ✓ | | Run, re-run, and cancel pipelines; deploy | ✓ | ✓ | ✓ | — | | Edit projects and release configurations | ✓ | ✓ | ✓ | — | | Create and manage workspaces, projects, environments, and databases | ✓ | ✓ | — | — | | Edit environment variables | ✓ | ✓ | — | — | | Invite, edit, and remove members | ✓ | — | — | — | | Connect Git providers | ✓ | — | — | — | | Billing, subscription changes, and organization settings | ✓ | — | — | — | Every role can _view_ environment variables, members, and the subscription; the table above is about acting on them. ### Workspace and project roles Roles are **scoped**: a member can hold one role across the organization and a different one in a specific workspace or project — broad access in one workspace, none in another. Scoped roles come in the same flavors, narrowed to their scope: - **Maintainer** (workspace or project) — manages everything inside that scope: projects, environments, release configurations, pipelines, deployments, and the scope’s environment variables and members. - **Developer** (workspace or project) — works on what already exists: edits projects, runs pipelines, creates and edits release configurations. Can’t create projects or environments. A _project_\-scoped Developer can run pipelines but not trigger deployments — that stays with workspace-level roles and Maintainers. - **Viewer** (workspace or project) — read-only across the scope, including logs, metrics, and vulnerability findings. Managing members and their roles is covered under [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/). Note The tables reflect the platform’s current permission configuration. When in doubt, what the UI offers a member is authoritative — actions a role doesn’t hold simply don’t appear. --- **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** (region), 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 that reflects the instance’s current state and the last change made to it. ## The database lifecycle A database moves through a small set of states, shown on its overview: - **Provisioning** — Salus is creating the instance. Settings can’t be changed yet. - **Active** — the instance is running normally. This is the only state in which you can change resources or rotate the password. - **Updating** — a change is rolling out (a resize, a version upgrade, or a password rotation). Settings are locked until it completes. - **Suspended** / **Unavailable** — the instance isn’t currently serving connections; check its overview for the cause. - **Failed** / **Error** — the last change didn’t complete successfully. - **Deleting** — the instance is being torn down. Whenever the database isn’t **Active**, changes are temporarily disabled — wait for the current process to complete and try again. ## In this section - [Provision a database](https://salus.cloud/docs/deployments/databases/provisioning/) — tiers, naming, and the one-time admin password. - [Connect a database](https://salus.cloud/docs/deployments/databases/connect/) — link it to a project, or connect manually; endpoints and network access. - [Manage a database](https://salus.cloud/docs/deployments/databases/manage/) — resize, upgrade, rotate the password, and delete. --- **Source:** https://salus.cloud/docs/deployments/databases/connect/ DocumentationConnect a Database Deployments # Connect a Database ## 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 region** 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. A **linked project can only communicate with its database over the internal DNS** — the injected `SALUS_DATABASE_*` variables point there. - **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. The **Public Network** setting (“Expose database to the public”) enables the external endpoint and shows its public DNS name. Leave public access off unless something outside Salus genuinely needs to connect — your own deployments never need it. ## Troubleshooting - **A linked project can’t reach the database.** A linked project can only communicate over the database’s **internal DNS** — pointing it at the external (public) hostname doesn’t work. Connect using the injected `SALUS_DATABASE_*` variables, which resolve to the internal endpoint. - **Can’t connect from your local machine.** The internal endpoint isn’t reachable from outside Salus — enable **Public Network** and connect to the external endpoint, with TLS, on port 5432. - **Authentication fails on a manual connection.** The connection string you fetch later has the password masked — use the password you saved at creation, or [rotate it](https://salus.cloud/docs/deployments/databases/manage/) for a fresh one. --- **Source:** https://salus.cloud/docs/deployments/databases/manage/ DocumentationManage a Database Deployments # Manage a Database Everything here lives in the database’s **Settings**, and requires the database to be **Active** — while it’s provisioning, updating, or deleting, changes are temporarily disabled. ## Resize compute and storage **Compute** (CPU/memory tier) and **storage** are changed — and saved — independently: - **Scale compute** by moving the instance to a larger tier. Reducing resources isn’t supported yet — you can only scale up. - **Grow storage** to a larger size. Storage is **grow-only**, and you can’t select a size below what the instance already uses — so raise it deliberately. ## Upgrade the PostgreSQL version Change the **engine version** from the General settings 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. ## Rotate the admin password If you’ve lost the admin password — or just want to retire it — use **Rotate password** on the database’s overview. Rotation is available only while the database is **Active**. Rotating generates a new password and shows it **once**: copy it immediately, it won’t be shown again. The database moves to **Updating** while the change rolls out — the current password keeps working until the database returns to **Active**, at which point the new one takes effect. Heads up Any projects connected with the old password may lose access after rotation — update their configuration with the new password. Projects [linked](https://salus.cloud/docs/deployments/databases/connect/) to the database get the refreshed credentials through their injected variables. ## Delete a database Deleting lives in the settings **Danger Zone**, and asks you to type the database’s name to confirm. Careful Deleting a database permanently deletes all data, configurations, and backups. This action can’t be undone. ## Troubleshooting - **Settings are disabled.** Changes are blocked while the database is provisioning, updating, or deleting — wait for it to return to **Active**. - **You can’t pick a smaller tier or storage size.** Downsizing isn’t supported: compute only scales up, and storage can’t go below current usage. - **Apps lost database access after a rotation.** Update any hand-configured connection details with the new password; linked projects receive it automatically. --- **Source:** https://salus.cloud/docs/deployments/databases/provisioning/ DocumentationProvision a Database Deployments # 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. If you lose it, [rotate the password](https://salus.cloud/docs/deployments/databases/manage/) to set a new one. The new instance starts in **Provisioning** and becomes **Active** when it’s ready to accept connections — see [the database lifecycle](https://salus.cloud/docs/deployments/databases/). Next, [connect it to a project](https://salus.cloud/docs/deployments/databases/connect/). --- **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**, the detail view shows what’s running and how it’s set up: - **The release** — the deployed commit, with a link to it, and who triggered the deployment. - **Networking** — whether the deployment is public or private, its port, the public URL and any custom domain, and its private DNS name. - **Resources** — the memory and CPU sizes it runs with, and its minimum/maximum instance counts. - **Associated pipeline details** and the Automated Deployment status. Note The **Observability** button takes you straight to the deployment’s performance metrics — see [Metrics](https://salus.cloud/docs/observability/metrics/). ## Deployment history and rollback Each environment keeps a history of its **deployment revisions**, so you can see what was released and when — and roll back when a release causes trouble. See [Deployment History & Rollback](https://salus.cloud/docs/deployments/revisions/). --- **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. Each environment also chooses its **region** when it’s created, so one organization can run environments across several regions and clouds at once. ![](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”. Choose the environment’s **region** — where its workloads will run. Your organization’s default region is pre-selected, and each option is labelled with its provider. Tip The regions offered here are the ones enabled for your organization. Manage them — and set the default — from the [Regions page](https://salus.cloud/docs/getting-started/organizations-and-teams/) in your organization settings. ### 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. ### 🎉 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 ## Delete an Environment You can delete an environment you no longer need — a preview, a spike, or an old staging setup — from your workspace’s environments list. The option appears only if your role allows deleting environments, and you’ll be asked to type the environment’s name to confirm. Before you confirm, Salus checks whether any projects are still running in the environment and tells you what it finds — environments are shared across a workspace, so more than one project can be live in the one you’re deleting. Careful Deleting an environment can’t be undone, and any deployments still running in it are torn down. Wait for the running-projects check before you confirm, and don’t proceed unless it reads the way you expect. This is different from deleting a **configuration** (above), which removes a single project’s setup for an environment. Deleting the environment itself removes it for every project in the workspace. ## Troubleshooting - **A variable change isn’t taking effect.** Changes apply only after the deployment is **redeployed** — trigger one and check again. - **Can’t create a variable starting with `SALUS_`.** That prefix is reserved for values Salus injects (like linked-database credentials) and is blocked on your own variables. - **The app is deployed but unreachable.** Check that **Expose application to public** is enabled if you’re connecting from the internet, and that the configured **port** matches what your app listens on (Salus defaults to `8080`). - **The region you want isn’t offered when creating an environment.** Only regions enabled for your organization appear — an admin can enable it on the organization’s Regions page. --- **Source:** https://salus.cloud/docs/deployments/revisions/ DocumentationDeployment History & Rollback Deployments # Deployment History & Rollback Each environment keeps a **deployment history**: every revision that was released into it, newest first. ## What the history shows Each revision carries: - **Status** — Pending, In progress, Successful, Failed, or Cancelled, with the current release marked as the **latest deployment**. - **What was deployed** — the commit message, branch or tag, and commit hash, plus who triggered it. - **Deployment type** — whether the revision came from a **pipeline** run or a **rollback**. - **Resources** — the compute the revision ran with. ## Roll back a release If a release causes trouble, you can **roll back** to an earlier revision to restore a previous known-good deployment. A **Rollback** button appears on revisions that are eligible — not every revision qualifies. Rolling back: 1. **Redeploys the selected revision** and replaces the current release. 2. Takes the currently running deployment **out of rotation**. You’ll be asked to confirm against the revision’s commit before anything happens. The rollback itself appears in the history as a new revision of type _Rollback_, so the record stays complete. Heads up A rollback restores the **application build** — it doesn’t rewind environment variables or database contents. If the incident involved configuration or data changes, address those alongside the rollback. ## Troubleshooting - **A revision has no Rollback button.** It isn’t eligible for rollback — pick another known-good revision that is. - **You rolled back but the bad behavior persists.** Check whether the cause was configuration or data rather than the build — variables and databases aren’t rewound by a rollback. --- **Source:** https://salus.cloud/docs/faqs/ DocumentationFAQs # FAQs Quick answers to the questions we hear most, with links to the full docs. ## Getting started **Which Git providers can I connect?** GitHub and GitLab, connected at the organization level. See [Git Management](https://salus.cloud/docs/getting-started/git-management/). **Which languages and frameworks are supported?** JavaScript/TypeScript projects and .NET (C#) build with zero configuration via buildpacks; anything with a Dockerfile runs as a custom Docker build — Python, Go, Java, PHP, Ruby, and more. See [Supported Stacks](https://salus.cloud/docs/getting-started/supported-stacks/). **Do I need a Dockerfile?** Only for stacks the buildpacks don’t cover. For supported stacks, Salus detects your project and builds it without one. See [Buildpacks](https://salus.cloud/docs/pipelines/builds/buildpacks/). **Can my AI coding assistant use Salus?** Yes — the Salus MCP server connects assistants like Claude Code, Cursor, and Claude Desktop to your projects, deployments, logs, and databases. See [MCP](https://salus.cloud/docs/mcp/). ## Organizations and teams **What’s the difference between the roles?** Owner, Maintainer, Developer, and Viewer range from full control to read-only, and they’re scoped — a member can hold different access in different workspaces or projects. See [Access Control](https://salus.cloud/docs/deployments/access-control/). **Why does a member show as “Guest”?** They accepted an invitation to a specific workspace or project without being an organization member — Salus creates the Guest placeholder automatically. Their real access is the scoped role from the invitation. See [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/). **Who can deploy to which region?** Admins enable regions and set the default on the organization’s Regions page; environments pick from the enabled set when they’re created. See [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/). ## Deployments and networking **Is my application public by default?** No — deployments are private unless you enable **Expose application to public** on the release configuration. See [Access Control](https://salus.cloud/docs/deployments/access-control/). **What domain does my app get?** Every publicly exposed application gets a free Salus domain automatically, and you can configure a custom domain. See [Environment Configurations](https://salus.cloud/docs/deployments/environment-configurations/). **What port should my app listen on?** Whatever you configure — Salus defaults to `8080`. **A release went bad — can I roll back?** Yes. Each environment keeps a history of deployment revisions, and you can roll back to an earlier eligible revision. See [Deployments](https://salus.cloud/docs/deployments/deployments/). ## Environment variables **Where should I set a variable that several projects need?** At the highest level that owns it: variables merge down **Organization → Workspace → Project → Release configuration**, with the closest level winning. See [Environment Configurations](https://salus.cloud/docs/deployments/environment-configurations/). **Why can’t I create a variable starting with `SALUS_`?** That prefix is reserved for values Salus injects — like a linked database’s connection details — so they can never be shadowed by your own variables. **My variable change isn’t taking effect.** Variable changes apply only after the deployment is **redeployed**. ## Databases **I lost my database admin password.** It’s shown only once, at creation. Rotate the password to set a new one. See [Databases](https://salus.cloud/docs/deployments/databases/). **Can a project use a database in a different region?** No — a database can only be linked to an environment in the same region as the database. ## Logs and billing **How long are my logs kept?** Per your plan’s retention policy. Download anything you need to keep before it ages out. See [Logs](https://salus.cloud/docs/observability/logs/). **How does billing work?** Your plan, credit balance, payments, and usage are 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/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** and **GitLab**. 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 --- **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, your managed databases, and the regions your environments can run in. Everything else — workspaces, projects, and environments — lives inside it. ## Create an organization Create an organization and give it a name (letters and numbers only). If more than one region is available to you, you’ll also pick the region your organization starts in. Once the organization 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 role, **Guest** — and it works differently from the other four: - **You never assign it, and you can’t.** Salus creates it automatically when someone accepts an invitation to a specific workspace or project without already being a member of your organization; attempts to grant Guest manually are rejected. - **Organization-wide, a Guest can do almost nothing.** They can see the list of workspaces, the organization’s connected Git providers, and application logs — just enough for the app to work. No projects, no settings, no billing. - **Their real access is the scoped role their invitation carried.** A Guest invited as a Developer on one project is a Developer there and a Guest everywhere else. - **To widen their access**, assign them one of the four organization roles from your members list — that replaces the Guest placeholder. 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 and GitLab. See [Git Management](https://salus.cloud/docs/getting-started/git-management/). ## Regions Your organization controls which **regions** — cloud locations across providers — its environments can run in. The **Regions** page in your organization settings lists every region available to you, labelled by provider and location, along with how many deployments are currently active in each. If you have permission to manage organization settings, you can: - **Enable or disable regions**, so builders pick from a curated set rather than everything on offer. - **Set the default region** — the one pre-selected whenever someone creates a new environment. Each environment chooses its region when it’s created, from the regions enabled here — so one organization can run across several regions and clouds at once. See [Environment Configurations](https://salus.cloud/docs/deployments/environment-configurations/). ## 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 or GitLab, 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, 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 vulnerability scanning stage is informational by default. Later, you can require it 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 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 Any framework that can run in a container can run on Salus — your application deploys as it is, without being rewritten to fit the platform. There are two build paths. ## Zero-config builds (buildpacks) When you import a repository, its [buildpacks](https://salus.cloud/docs/pipelines/builds/buildpacks/) detect the project and run the right install and build commands for you. Supported out of the box: - **Frontend** — React (Vite or Create React App), Vue, Svelte, and static-site frameworks such as Astro and Nuxt. - **Full-stack and server-rendered** — Next.js (server or static export), Nuxt, and similar frameworks with server logic. - **Node.js backend services** — APIs and services built with frameworks such as Express, NestJS, or Fastify. JavaScript and TypeScript projects are detected from their `package.json` and lockfile. - **.NET (C#)** — web services and APIs such as ASP.NET Core applications. 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. ## Every other stack: custom Docker builds Python (Django, Flask, FastAPI), Go, Java and Kotlin (Spring Boot), PHP (Laravel), Ruby on Rails — anything with a Dockerfile builds and runs on Salus as a **custom Docker build**. You bring the Dockerfile; Salus builds the image and runs it as a real, long-lived service. See [Custom Docker Builds](https://salus.cloud/docs/pipelines/builds/custom-docker/). --- **Source:** https://salus.cloud/docs/mcp/ DocumentationMCP # MCP Salus is MCP-native: your AI coding tools connect to the platform through the **Salus MCP server**, so assistants like Claude Code, Cursor, Codex, OpenCode, and Claude Desktop can work with your projects, deployments, logs, and databases on your behalf. The server ships inside the Salus CLI — a single binary, `salus`. ## 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. ## In this section - [Getting started](https://salus.cloud/docs/mcp/getting-started/) — install the server and connect it to your AI tools. - [Use cases & sample prompts](https://salus.cloud/docs/mcp/use-cases/) — what teams do with Salus through an assistant, each with a prompt to start from. ## Latest release These links always point at the latest build: - **macOS (Apple silicon)** — [https://download.salus.cloud/salus-darwin-arm64](https://download.salus.cloud/salus-darwin-arm64) - **macOS (Intel)** — [https://download.salus.cloud/salus-darwin-x64](https://download.salus.cloud/salus-darwin-x64) - **Linux (arm64)** — [https://download.salus.cloud/salus-linux-arm64](https://download.salus.cloud/salus-linux-arm64) - **Linux (x64)** — [https://download.salus.cloud/salus-linux-x64](https://download.salus.cloud/salus-linux-x64) - **Claude Desktop extension** — [https://download.salus.cloud/salus-mcp.mcpb](https://download.salus.cloud/salus-mcp.mcpb) If you download a binary directly, rename it to `salus` and make it executable. Editor configuration snippets and the MCP registry entry (`server.json`) live on the [Developers page](https://salus.cloud/developers/). --- **Source:** https://salus.cloud/docs/mcp/getting-started/ DocumentationMCP: Getting Started # Getting Started with MCP ### 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. Direct per-platform downloads are on the [MCP overview](https://salus.cloud/docs/mcp/). ### 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 on the [Developers page](https://salus.cloud/developers/) — 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. ### 🎉 Start prompting Ask your assistant something real — the [use cases & sample prompts](https://salus.cloud/docs/mcp/use-cases/) are a good place to start. Remember you control its access level from **Read-only** up to **Full**; start restrictive and widen as you need. ## Troubleshooting - **Your editor doesn’t list the Salus tools.** Check the MCP configuration points at the installed binary (`/usr/local/bin/salus`) with the `mcp` argument, then restart the editor so it re-reads the config. - **The sign-in browser window never opened.** The server also prints a sign-in link — open it manually and complete authentication there. --- **Source:** https://salus.cloud/docs/mcp/use-cases/ DocumentationMCP: Use Cases & Prompts # Use Cases & Sample Prompts Five things teams do with Salus through an assistant. Paste a prompt and adapt the names to your organization. ## Ship from your editor Create a project, deploy it, and let the assistant watch the pipeline through to live. ```text Deploy this repository to my staging environment. Watch the pipeline and tell me when it's live — if the build fails, show me the failing step's logs and explain what went wrong. ``` ## Diagnose production Pull logs, metrics, and revision history, and get an explanation instead of raw output. ```text Pull the last hour of logs for checkout-api in production, group the errors, and explain the most frequent one. Has it gotten worse since the last deployment? ``` ## Stay on top of security Have vulnerability findings prioritized and explained against your actual dependencies. ```text Check my production environment for vulnerabilities. Which ones are critical, and which of our services do they actually affect? Suggest what to upgrade first. ``` ## Manage configuration Work with environment variables across the hierarchy without clicking through settings. ```text List the environment variables my staging deployment actually resolves, and tell me which level each one comes from. Then set LOG_LEVEL to debug on staging only. ``` ## Operate infrastructure Provision databases, roll back releases, or take a deployment offline — with confirmation before each step. ```text The latest production release of checkout-api is misbehaving. Show me its recent deployment revisions and roll back to the last known-good one. ``` Tip **Read-only** access can diagnose but not act — give the assistant **Operator** or **Full** only where you want it acting. See the [MCP overview](https://salus.cloud/docs/mcp/). --- **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 at a glance how your log volume breaks down across severity levels 4. View the log table showing the log details, timestamp, and severity 5. Chart log volume per severity over time — the chart adapts its intervals to the time range you select ![](https://salus.cloud/docs-assets/image-45.webp) Heads up Logs are retained per your plan’s **retention policy**. Entries older than your retention window are no longer available, so download anything you need to keep. - **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 a Region Logs are scoped to a **region** — where your workloads run. The filter starts on your organization’s default region, so you can go straight to the other filters; switch it to see logs from workloads running in a different region. ### 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 ## Troubleshooting - **No logs are showing.** The granular filters activate only after you select a **workspace** — pick one first, then narrow by environment and project. Also check the **region** filter: logs are scoped to the region your workloads actually run in. - **Older entries are missing.** Logs age out per your plan’s retention policy — download anything you need to keep before it does. - **A project doesn’t appear in the filter.** Only projects with configured deployments show up; check the project has a release configuration in the selected environment. --- **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. 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. From a project’s [deployment page](https://salus.cloud/docs/deployments/deployments/), click the **Observability** button — it takes you straight to that deployment’s metrics. (The button activates once the environment is configured and has a deployment.) 2. Click the metrics icon on the left-hand navigation panel and select from the list of existing projects in your workspace. ![](https://salus.cloud/docs-assets/image-44.webp) ## What you see Three charts, side by side, for the deployment you’ve selected: - **Request rate** (requests/second) — immediate recognition of traffic spikes, aiding scaling decisions, infrastructure planning, and keeping user experience healthy during peak times. - **Error rate** (% of requests) — a rising error rate is your earliest trigger for investigation, before users start telling you about it. - **Request duration** (milliseconds, at the **75th, 95th, and 99th percentiles**) — not just the average but the outliers, so you can target optimizations where they matter. Charts cover the **time range you select** — the default is the last 30 minutes, and you can widen it with the range filter. How far back you can look is bounded by your plan’s metrics retention policy. --- **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 stack — JavaScript/TypeScript frameworks (React, Vue, Next.js, and others) as well as .NET (C#) applications — and runs the right commands. No build files to write, and no Dockerfile needed. 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, ASP.NET Core, 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/). - **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 stage, so a build that fails it 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** — the overall pipeline status. Learn more about [pipeline status types](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 | | --- | --- | | 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. | ## 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, Security and Deploy - **Status Badge i.e.** Success, Pending, Skipped, Error, Cancelled - **Associated Tasks** i.e. Git-clone, Build 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 **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 ## **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, 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 per your plan’s **retention policy**, counted from the pipeline’s trigger date. Once they age out they’re no longer available, so download anything you need to keep. 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 **five stages:** - Prepare - Build - Unit testing - Package vulnerability scanning - Deploy ![](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. ## Trigger methods A pipeline run starts one of two ways: - **Automatic** — Salus starts a run when your tracked source changes: a push to the tracked **branch**, or a new **tag**, depending on the deployment strategy chosen in the environment’s [release configuration](https://salus.cloud/docs/deployments/environment-configurations/). This is the continuous-delivery default. - **Manual** — you start a run yourself from Salus, building the current state of the tracked branch or tag. Use this to redeploy without a new commit, or when you want to control exactly when a release happens. Each run’s **Trigger method** column shows which of the two started it, alongside who triggered it and when. ## 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. ## Troubleshooting - **The pipeline failed at a quality or security stage.** Open the stage’s report in [pipeline details](https://salus.cloud/docs/pipelines/pipeline-details/) to see what failed. If the stage is set as a gate in [pipeline rules](https://salus.cloud/docs/pipelines/pipeline-customization/), the run stops there by design until the underlying issue is fixed. - **The pipeline succeeded but nothing deployed.** Check the environment’s **Automated Deployments** setting — when it’s off, a successful build waits for you to deploy manually. - **You need to stop a run.** Use **Cancel** on the run — it works while the run is still pending, waiting, or in progress. --- **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. - [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/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/register)[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. An agent works with its human's scoped access and is recorded as that person — 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/register)[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. | | [Terms of Use](https://salus.cloud/legal/terms-of-use/) | — | On use | The rules for using this website. | | [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/legal/terms-of-use/ [Legal](https://salus.cloud/legal/) # Terms of Use Welcome to the Salus Cloud website (the "Site"). These Terms of Use ("Terms") govern your access to and use of the Site, operated by Salus Cloud Corporation, a technology company headquartered in Delaware ("Salus," "we," "our," or "us"). By accessing or using this Site, you agree to comply with and be bound by these Terms. If you do not agree to these Terms, you must not use the Site. Please read the following carefully. ## 1\. Acceptance of Terms By accessing and using the Site, you acknowledge that you have read, understood, and agreed to be bound by these Terms, as well as our Privacy Policy, which is incorporated by reference. We may modify these Terms from time to time, and any such modifications will be effective immediately upon posting to the Site. Your continued use of the Site following the posting of updated Terms will mean you accept those changes. ## 2\. Use of the Site **2.1 Eligibility:** You must be at least 13 years old to use this Site. By using the Site, you represent and warrant that you have the right, authority, and capacity to enter into these Terms. **2.2 License:** Salus grants you a limited, revocable, non-exclusive, non-transferable license to access and use the Site solely for personal, informational, and non-commercial purposes. **2.3 Prohibited Conduct:** You agree not to: - Use the Site for any unlawful purpose. - Attempt to gain unauthorized access to any portion of the Site. - Interfere with the Site's operations or integrity, including by introducing viruses or harmful code. - Copy, modify, distribute, or otherwise exploit the content of the Site without prior written consent from Salus. - Engage in any conduct that may harm the reputation of Salus or infringe on the rights of others. ## 3\. Intellectual Property **3.1 Ownership:** All content on this Site, including text, images, logos, software, and other materials (collectively, "Content"), is the property of Salus or its licensors. You may not use, modify, reproduce, distribute, or display any portion of the Content without prior written consent from Salus. **3.2 Trademarks:** Salus Cloud, the Salus Cloud logo, and any other trademarks displayed on this Site are trademarks of Salus or third-party licensors. You are not permitted to use these trademarks without prior written permission from Salus or the respective owners. ## 4\. Third-Party Links The Site may contain links to third-party websites or services that are not owned or controlled by Salus. We are not responsible for the content or practices of any linked third-party sites. You access any third-party websites at your own risk. ## 5\. Disclaimers **5.1 No Warranties:** The Site and its Content are provided on an "as is" and "as available" basis. Salus makes no representations or warranties of any kind, express or implied, about the accuracy, reliability, completeness, or timeliness of the Content or the Site's operation. **5.2 Limitation of Liability:** To the fullest extent permitted by applicable law, Salus shall not be liable for any direct, indirect, incidental, special, or consequential damages resulting from the use or inability to use the Site, including any damages for loss of data, loss of profits, or business interruption. ## 6\. Indemnification You agree to indemnify, defend, and hold harmless Salus and its officers, directors, employees, and agents from and against any and all claims, damages, liabilities, costs, and expenses (including reasonable attorneys' fees) arising from your use of the Site, your violation of these Terms, or your violation of any rights of a third party. ## 7\. Governing Law These Terms are governed by and construed in accordance with the laws of Delaware, without regard to its conflict of law principles. You agree to submit to the exclusive jurisdiction of the courts located in Delaware for the resolution of any disputes arising from these Terms or your use of the Site. ## 8\. Termination We reserve the right to terminate or suspend your access to the Site at any time, without notice or liability, if we determine that you have violated these Terms or engaged in conduct that we deem harmful to Salus or other users. ## 9\. Severability If any provision of these Terms is found to be invalid or unenforceable, the remaining provisions will continue to be valid and enforceable to the fullest extent permitted by law. --- **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 2026 ### ISO 27001 In progress Audit completing — certificate expected 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 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. An agent acting for someone is recorded as that person — agents do not yet hold their own identity in the trail. 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 audit trail — append-only, naming the person whose access each action used, agent or not - 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.