Codesealer Enterprise is designed for high performance and high availability, and is comprised of the following components:

  1. A Redis instance or cluster for shared state,
  2. An InfluxDB 1.8 instance for metrics (optional),
  3. A Management Portal (core-manager),
  4. A number of Codesealer Worker processes (codesealer-core),

Kubernetes Deployment via Helm

The entire Codesealer setup can easily be deployed to a Kubernetes cluster using Helm, either in a standalone configuration or as a sidecar to an existing Kubernetes Ingress.

You can starting using our Helm chart by running the following command to add the Codesealer Helm chart repository to your list of repositories :

helm repo add codesealer

To learn more about how to use the Helm chart, check out the readme by running

helm show readme codesealer/codesealer

or visit the git repository for more information.


Codesealer Enterprise relies on Redis for the following functions:

  • Session state is stored and retrieved from Redis so that any Codesealer Worker can answer client requests.
  • New Bootloader instances are stored in Redis, ready to be retrieved by the Workers.
  • Configuration is pushed by the Management Portal to the Worker processes through Redis.
  • Internal state is stored and retrieved from Redis to assist with advanced features such as Application Network Protection.

Version requirements

Redis 6.2.0 and above.

Network requirements

Redis must be accessible for reading and writing from the Codesealer Worker processes and Management portal. The port is configurable - the default non-TLS Redis port is 6379.

Security considerations

No personally identifiable information is stored in Redis, but unauthorized access to Redis could degrade Codesealer security features, e.g. by exposing TLS certificates and keys added through the Management Portal and used by Codesealer Worker processes.

Codesealer recommends enabling TLS on Redis instances, as well as using strong credentials. When enabling TLS, the redis scheme changes to rediss://.


Codesealer Enterprise optionally relies on InfluxDB for metric collection. If InfluxDB is deployed and configured, these metrics will appear in the Management Portal. See the section on Metrics for more information.

Version requirements

Codesealer Enterprise supports InfluxDB versions 1.8.x.

Network requirements

The InfluxDB instance must be accessible from the following entities:

  • All Codesealer Worker nodes (codesealer-core),
  • The Codesealer Manager (core-manager),
  • Any customer-specific metric dashboards consuming metrics.

The InfluxDB port is configurable - the default non-TLS port is 8086.

Security considerations

Codesealer recommends TLS to be enabled on InfluxDB, as well as the establishment of strong credentials for authentication. Note, however, that no sensitive data is stored in InfluxDB. The data stored includes request- and error-rates at specific times.

Management portal

The Management Portal is needed to configure Codesealer Enterprise at runtime.

Network requirements

Administrators of Codesealer Enterprise must be able to access to the Management Portal over HTTP(s) on the configured port. The Management Portal itself must be able to access Redis.

Worker processes

The Codesealer Worker processes is the main component of Codesealer Enterprise, functioning as a reverse proxy.

Network requirements

The Codesealer Worker processes must be able access Redis for reading and writing, as well as being to able to write to InfluxDB if metrics are enabled.

A Codesealer Worker process acts as a HTTP(s) reverse proxy. It receives end user HTTP(s) requests and forwards the request to the backend. It then processes the content of these requests and responses.

Codesealer Worker processes can sit anywhere in the chain between the internet connection and final backend server. Other proxies and security products can be placed before and after Codesealer Worker processes. However, being placed behind a Load Balancer is recommended for High Availability configuration. As many Codesealer Worker processes as needed can be deployed.