Salus
Book a demo
DocumentationIntroduction

Introduction

Salus is a developer platform that gives engineering teams a paved road from commit to production. Connect a repository and Salus handles the rest of the software delivery lifecycle for you: it builds your application, runs your tests, scans your code and dependencies for problems, deploys the result to a managed environment, and then gives you the logs, metrics, and controls to run it in production.

In platform-engineering terms, Salus is an internal developer platform (IDP) delivered as a service. Instead of wiring together a CI server, a container registry, a secrets manager, a deployment tool, a database host, and an observability stack, you get one platform where security and quality checks are built into the path by default — not bolted on afterwards.

What you can do with Salus

  • Ship with automated pipelinesEvery push runs a DevSecOps pipeline — build, test, static analysis, and vulnerability scanning — before anything reaches production.
  • Deploy and scale applicationsConfigure environments, set resources and scaling, and deploy to managed infrastructure without writing deployment tooling.
  • Provision managed databasesCreate databases with the right resource tier, control network access, and wire connection details straight into your projects.
  • Observe what's runningCentralized logs and RED metrics (requests, errors, duration) across your deployments, in one place.
  • Let Salus Intelligence helpAn AI layer that surfaces insights across your pipelines, deployments, and security findings so you spend less time digging.
  • Manage your organizationInvite 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.

The delivery pipeline at a glance

When code lands, Salus runs it through a sequence of stages. Each stage produces its own report and logs, and you can require any stage to pass before a deployment is allowed.

  1. Prepare — fetch your source and set up the build context.
  2. Build — package your app using Salus buildpacks or your own Dockerfile.
  3. Unit testing — run your test suite and collect coverage.
  4. Static code analysis — surface bugs, code smells, and style issues.
  5. Package vulnerability scanning — check your dependencies for known vulnerabilities.
  6. Deploy — release the build into the target environment.
  7. Sync (Enterprise) — propagate the release to configured deployment targets.

See Pipelines for how stages, statuses, and rules work, and Pipeline Customization for blocking deployments when a check fails.

Where to go next