Skip to main content

Preparing Your Workload

Polaris runs your application unchanged. You bring a container, and Polaris wraps it in a confidential, attested environment: TLS, attestation, encryption, and continuous verification all happen around your app, not inside it. This page describes what makes a good fit, so you know what to expect before you deploy.

Most applications already meet these expectations. Where Polaris is opinionated, it is for a reason worth knowing, and each point below explains it.

The shape of a Polaris workload​

A good fit is a single web service in a container: it serves HTTP on one port, keeps its state in external systems, takes its configuration from the environment, and reaches only the networks it needs. If that describes your app, there is little to change.

Packaging​

  • One container per deployment. Polaris protects a single workload container in each confidential VM. Bundle everything that container needs into its image.
  • Built for linux/amd64. Confidential VMs run on AMD and Intel hardware, so images need an x86-64 build.
  • Bring an image or a Dockerfile. Point Polaris at a prebuilt image from your registry, or at a source directory it builds and pushes for you. Either way, the image you deploy is the one that runs.
  • Ship changes as new deployments. Polaris records the exact image it deployed and verifies that the running container still matches it, byte for byte. That check is what catches tampering, so releasing a change means deploying a new version rather than overwriting an existing tag in place.

Serving traffic​

Your application listens for plain HTTP on one port inside the environment. The Polaris proxy sits in front of it and handles everything security-related: it terminates TLS on the public side, proves the environment to the client through attestation, and forwards verified requests inward. Clients always reach your workload through the proxy over HTTPS, so your app never has to manage certificates or TLS itself. WebSocket traffic is supported.

Network access​

  • Inbound only through the proxy. Your workload does not expose ports of its own. All traffic arrives through the Polaris proxy, which keeps the attested boundary in one place.
  • Outbound is closed by default. A confidential workload reaches the Polaris control components and its own cloud's service endpoints out of the box. Anything else, a third-party API or an external database, you allowlist explicitly. This keeps a workload from quietly talking to places it should not, and it is easy to open up the destinations you do need.
  • No borrowing the VM's cloud identity. The workload cannot read the confidential VM's cloud credentials. This is deliberate: it means a compromised application cannot impersonate the VM to reach your keys and slip past attestation. Secrets reach your app through the attestation-gated key path instead, which is the whole point of the product.

Configuration and secrets​

  • Configuration comes from environment variables. Use them for flags and non-secret settings.
  • Secrets come from the attestation-gated key service. Keys are released only while the environment is verified healthy, so this path, not plain environment variables, is where API keys, tokens, and credentials belong.

State​

Treat the workload as stateless. Anything written inside the container is not preserved across a redeploy, so databases, queues, and object storage live outside the confidential VM and your app connects to them over the network. This keeps the protected boundary small and the workload easy to move and rebuild.

Privileges​

The workload runs with a minimal set of Linux privileges by default, which is good security hygiene and keeps the attested surface small. If your application genuinely needs a specific capability, you request it in the deployment config, where it becomes a reviewed, explicit part of the deployment rather than a silent default. A read-only filesystem is available as an option and is recommended where your app supports it.

Behaving predictably at runtime​

In its deepest attestation mode, Polaris learns what your workload normally does at runtime, its processes, network connections, and file activity, and then flags anything that departs from that baseline. Applications that behave predictably get the most out of this: a service that handles requests without constantly spawning new short-lived processes settles into a clean baseline and can run under the strictest enforcement.

Two things are worth expecting here:

  • Fresh deployments start in an advisory state. Right after launch, Polaris is still learning the baseline, so the runtime and image layers report advisory findings rather than enforcing. This is normal and clears once the baseline settles against a healthy, quiet workload.
  • Very dynamic workloads take more tuning. Applications that spawn many short-lived processes, run scheduled jobs, or rewrite their own executables are harder for the automatic baseline to pin down, so out of the box they tend to stay advisory. They still run, and still get platform and image attestation from the start. Bringing them under the strictest runtime enforcement is a matter of shaping the baseline to fit how the workload behaves, which we work through with you as part of onboarding.

Resources​

Polaris makes sure the attestation components always have the headroom to keep proving the environment, so a workload that spikes in memory or CPU cannot starve them and accidentally take verification offline. You can also set explicit CPU and memory limits for the workload in the deployment config when you want hard caps.

In short​

Bring a single, stateless, linux/amd64 web service that serves HTTP on one port, keeps secrets in the key service, and reaches only the networks it needs. Polaris handles the rest: confidential execution, attestation, encryption, and continuous verification, with no changes to your code.

Ready to deploy? Continue to Deploying Polaris.