Security
People sign in to Weik.io through single sign-on, and a grant can limit a person to one integration. Secrets are sealed with AES-256-GCM, and the audit log keeps every change for 400 days. Each control below links the docs page that shows how it works, and the page ends with how releases are tested and how to report a vulnerability.
The trust model
Sites open no inbound port. Each site connects out to the hub on port 443, and the hub publishes port 443 only, with TLS 1.2 and 1.3. Secrets are sealed with AES-256-GCM under a master key kept on the host. The audit stream can't be deleted or shortened with the backend's own credentials. A site's credential reaches only the projects and environments an admin allowed for it, such as finance in production.
- Both connections of a site go out to the hub on port 443, and a site opens no inbound port.
- The hub publishes port 443 only, with TLS 1.2 and 1.3.
- Secrets are sealed with AES-256-GCM under a master key kept on the host, outside the store and outside every backup.
- The audit stream can't be deleted or shortened with the backend's own credentials.
- A site's credential reaches only the projects and environments an admin allowed for its agent.
Controls
Identity and access
| Control | What it does |
|---|---|
| Single sign-on | Microsoft Entra ID and any OpenID Connect provider, with one button per provider on the sign-in page |
| Claim mappings | A provider's group claim becomes grants in Weik.io, so access follows your directory |
| Two-factor sign-in | An authenticator app with ten recovery codes, required of platform administrators, and a problem is raised while it is switched off |
| Local accounts | Limited to emergency use once single sign-on works, with passwords stored as PBKDF2-SHA256 with 600,000 iterations |
| Roles | Viewer, editor, deployer and admin, and custom roles made of the verbs you choose |
| Grants | A role on a project in the environments you choose, down to one integration or API, with every request denied unless a grant allows it |
| API keys | Minted with grants and an expiry, never wider than their owner's own grants, and shown once |
Docs: Sign-in and providers · Roles and grants · Two-factor sign-in · API keys




weikio member add line that does the same.Data protection
| Control | What it does |
|---|---|
| Sealed secrets | AES-256-GCM under a master key kept in a file on each backend host and never in a backup |
| Revealing a secret | A permission of its own that can be switched off per environment, and every reveal is audited |
| External secrets | A Dapr secrets sidecar fetches secrets from Azure Key Vault, HashiCorp Vault and the other stores Dapr supports |
| Sealed backups | Every backup archive is sealed before it leaves the hub |
| Immutable backup copies | S3 Object Lock in compliance mode, so no key, the hub's own included, can delete a copy early |
| Disk encryption | The hub's disks are encrypted by your cloud provider or with LUKS2, with step-by-step guides for Hetzner and bare metal |
Docs: Secrets · Encryption at rest




Network
| Control | What it does |
|---|---|
| Outbound-only sites | A site connects out to the hub on port 443 and opens no inbound port |
| Allowed networks | The hub can admit only the address ranges you list |
| Gateways | Each gateway lists the networks it admits and its client certificate policy, none, optional or required, with the authorities it trusts |
| TLS | Port 443 only, TLS 1.2 and 1.3, and only AEAD suites on TLS 1.2 |
| Certificates | Obtained and renewed by the platform for the hub's names and every gateway hostname |
| Subscription keys | An API key is shown once and stored only as a hash, and each subscription has its own rate limit and expiry date |
| Sessions | The admin UI's session cookie keeps the __ prefix on the same origin as the API, with no CORS |
Docs: Allowed networks and TLS · Network
Audit and monitoring
| Control | What it does |
|---|---|
| Every change | Each change through the API, the CLI, a GitOps apply or the admin UI writes a record with its diff, actor, reason and commit |
| More than changes | Sign-ins, secret reveals, enrolments, revocations, break-glass access, backups, restores and every read of the audit itself are recorded too |
| Retention | The audit trail is kept 400 days and can be forwarded to your SIEM |
| A trail that stays | The audit stream can't be deleted or shortened with the backend's own credentials |
Docs: Audit log · Telemetry forwarding




weikio audit query line above the filters runs the same search.Emergency access
| Control | What it does |
|---|---|
| Break-glass accounts | Sign in only while a window opened on the hub host is open, for 1 to 72 hours, from the addresses the window lists |
| When everything else is down | The break-glass commands run on the hub host and work while every backend is down, and every request is audited and can be posted to a webhook |
Docs: Break-glass access
Supply chain and builds
| Control | What it does |
|---|---|
| Exact images | images. lists every image of a release with its tag and digest, and no image is tagged latest |
| Licences | Every image contains its licence, notice and third-party notices, and each release checks them before it is published |
| Checksums | The installer and the install scripts check SHA256SUMS before they use a file |
| Signed CLI | The Windows CLI is signed with Authenticode by Adafy Oy, with a timestamp |
| Isolated builds | Builds run with Landlock on Linux 6.7 and later, which limits what a build can read, write and connect to |
| Token keys | The backend signs tokens with ES256 keys that are stored sealed and rotated every 90 days |
How releases are tested
Before 2026.2.0 was released, its release candidate ran for 24 hours on a three-server hub with 250 deployments and 34 events a second. During the run, drills paused one storage server for 30 seconds, stopped the telemetry stores for 15 minutes and cut a site off from the hub for 15 minutes. Of the 243,468 probe calls, the only failures came during the 30-second pause the test caused on purpose, and the stores received every telemetry record the sites sent.
Adafy's security team, which is separate from the development team, then tested the release candidate from the internet and found nothing rated critical or high.
Before the release candidate was built, a dependency check found no vulnerable package among the 56 NuGet packages of the platform's 10 projects. The end-to-end suite runs over the release images, and each release checks the licence of everything its images contain.
Report a vulnerability
Write to security@weik.io or use GitHub's private vulnerability reporting on weikio/weikio, with the release, the steps to reproduce and what you saw.
The policy is in SECURITY.md on GitHub and in /.well-known/security.txt. Fixes ship as patch releases, and the release notes of the fixing release describe them.
Weik.io Cloud
Weik.io Cloud is operated by Adafy Oy under Finnish law, and its servers run in Hetzner's data centre park in Helsinki. The park is ISO/IEC 27001 certified, and the certificate belongs to the data centre operator, Hetzner Online GmbH. The sovereignty page of weikio.cloud links the data processing agreement and the list of subprocessors.
Questions
Where is my data stored?
Everything a self-hosted Weik.io stores stays on your hub and your sites. How Weik.io is put together lists where each kind of data lives and for how long.
Who can read secret values?
Only people whose role has the reveal permission in that environment, and every reveal is audited. An environment such as production can switch reveals off for everyone.
Can Adafy's staff reach my installation?
They have no access to a self-hosted installation. When you create an account for them during a support case, your audit log shows everything they do with it.
How do I hear about security fixes?
Watch releases on GitHub or follow the releases feed. Customers with a support subscription get security advisories before publication.
Book a demo
An engineer from the Weik.io team answers your security questions during the demo.