Announcement4 min read

Maintenance Update: Safer Defaults, Cleaner Installs, and Quieter Operations

A maintenance release focused on safer first-run defaults, verified installs, cleaner Kubernetes health checks, and stronger handling of sensitive settings.

1S

Core Platform Team

maintenancesecurity hardeninginstallerkubernetesrelease trustoperations

What Changed

This is a maintenance release, not a flashy feature launch. The goal was to make normal operation safer, clearer, and easier to trust.

New installs now start with a more conservative local API posture. Sensitive values are less likely to appear in config, log, or export output. The installer has clearer support for pinned, verified releases. Kubernetes health checks now use the simple health endpoint instead of an authenticated status path, and the chart defaults are quieter about what they expose inside the cluster.

Safer First Run Defaults

The engine now listens locally by default. That keeps a fresh install useful for the CLI and local dashboards without quietly opening a wider network surface.

If you intentionally expose the API to another host, add an API key or a read-only key first. Health checks still work through /health, so probes and load balancers do not need broad API access just to know whether the engine is alive.

More Confidence in Updates

The install path is now friendlier to production change control. You can pin the exact release you want, and the default installer verifies the signed checksum bundle before installing.

Release artifacts also carry stronger provenance signals for teams that audit their software supply chain. You do not need to change how you use 1-SEC day to day, but the evidence around what you installed is stronger.

Kubernetes Is Quieter

The Helm chart now treats health checks, API access, and the embedded event bus more deliberately. Probes use /health. NATS is not exposed through the Service unless you explicitly enable it. NetworkPolicy defaults are present so cluster traffic starts from a more controlled shape.

For most operators, this simply means fewer surprises. For production teams, it gives you clearer switches when you do want to expose something.

What Operators Should Do

Update normally, but pin the version in production so rollouts are repeatable. If your API is exposed beyond the local machine, set an API key or read-only key and keep unauthenticated reads disabled. If you run the Helm chart and intentionally need NATS access from another workload, enable that value directly and scope the NetworkPolicy source.

No module behavior needs to be relearned. This pass is about making the surrounding maintenance path safer while keeping the 1-SEC operating model the same: one engine, local-first protection, and fewer moving parts than a traditional security stack.

Try 1-SEC Today

Open source, single binary, 16 security modules. Download and run in under 60 seconds.