Run Crunu inside your own network. The internet is optional.
The whole Crunu server installs from one signed archive onto a host in your network: the server, the web app and the agent releases. It works with or without internet access, and you decide which hosts it may reach. It still stores only ciphertext.
Your network, your rules
Switch the view to see what each part of the network does. The installer starts the server isolated; opening a door is your choice.
The default after install
The installer writes ISOLATED=1 with an empty allow-list. Agent releases and the web app come from the server itself. Email, webhooks and the sign-in keys of cloud CI services are refused before any connection is made.
Open the doors you need
List the hosts the server may reach in OUTBOUND_ALLOW: a webhook receiver and a CI system in your network, and, if you want alert email, the mail service on the internet. Everything else stays refused, and the web app, the server log and doctor all report the mode.
Work goes on while the server is down
People open the encrypted copy of their vaults on their own device and keep changes as drafts, which they sync after the next sign-in. Agents keep serving from an encrypted cache until their lease ends, 24 hours by default.
Delivery
Everything arrives in one signed archive
Your Enterprise agreement comes with the bundle, its SHA-256 and the release public key. Carry the archive into the network; nothing else needs to cross the line.
- Docker images of the server, Caddy and Postgres
- The signed web app and agent releases for amd64 and arm64
- The installer, the operator tools and the guides
- A manifest of every file and image, signed with the release key
The installer checks the bundle against its signature before it loads a single image, and refuses files it didn’t write, such as a planted settings file.
Isolated mode
Four kinds of request could leave the server. You decide which may
The list is short because the server is blind by design: it has nothing to report home. These are the only outgoing requests in the code, and each one passes the same filter.
| Request | On a connected install | In isolated mode |
|---|---|---|
| Agent releasesInstall and update commands | The release directory | Served by the server itself from /releases/ |
| Alert emailSent through Resend | api.resend.com | Refused unless api.resend.com is in OUTBOUND_ALLOW. Alerts always show in the web app |
| WebhooksAlert receivers you add | Any receiver | Only hosts in OUTBOUND_ALLOW, such as hooks.kiteline.example |
| CI sign-in keysOIDC keys of a CI system | Your CI provider | Only a CI system the server can reach, listed in OUTBOUND_ALLOW |
Your firewall stays the real boundary. Isolated mode is a promise of the server’s own code: it never addresses a host outside the list. Docker doesn’t stop a container from reaching outside, so the install guide includes host firewall rules for a block at the network level.
Install
From archive to a running server in three commands
You need one Linux host with Docker and Node.js 24, ports 80 and 443 reachable inside the network, and a DNS name for the server.
1Unpack the checked archive
Compare its SHA-256 with the one you received before you run anything from it.
2Run the installer
Loads the images, writes new keys, starts Docker Compose and runs
doctor. It prints the token for the first owner.3Hand out the root certificate
Install it in the browsers and systems that open Crunu. Compare the fingerprint on every machine.
When the server is down
A maintenance window doesn’t stop the team
Each person can keep an encrypted copy of their vaults on their own device. It opens with their password and Secret Key, with no server at all.
- Read, search and copy values while the server is unreachable
- Edits are saved as drafts on the device and are never signed offline
- After sign-in, each draft becomes a version through the normal signed save, with a merge if the environment changed meanwhile
- Agents keep serving from an encrypted cache until their lease ends
Environments restricted to certain networks never go into the offline copy or the agent cache.
Machines and CI
Agents and pipelines install from your own server
The server hosts the signed agent releases at its own address. Machines and runners never need the internet to install or update the agent.
Tick one box and the install command trusts your certificate authority. The agent keeps a copy in /etc/crunu/ca.pem, and sudo crunu self-update later updates it from your server.
Runners use a crunu binary from the bundle that’s already in their image, so nothing is downloaded during the job. GitHub Actions, GitLab CI and the Bitbucket pipe all support this.
What to plan for
Known limits of an on-premises install today. The guides cover each one.
- A Linux host with DockerFor one computer only, there are also a local Docker mode and a Node.js mode without Docker, both on localhost.
- A DNS name, not an IP addressAn IP address works, but passkeys need a name. Sign-in with an authenticator app works either way.
- Synchronized clocksThe internal certificate authority issues certificates for 12 hours and renews them, so the server and every machine need NTP.
- Email goes through the internetAlert email uses an internet service. Email through your own mail server isn’t in this release; webhooks inside your network work.
- CI inside the networkSign-in from a cloud CI service needs its keys from the internet. Allow its host, or use a CI system in your network.
- You run the backupsThree things to keep apart: the database volume, the settings file with the server key, and the volume of the internal certificate authority.
Guides for operators
- Install Crunu in your own networkCheck the bundle, run the installer, create the first owner
- TLS and the root certificateInternal certificate authority, your own certificate, trust on each system
- Isolated mode and allowed hostsOUTBOUND_ALLOW, what is refused, firewall rules
- Machines and CI in your network--ca-file, CRUNU_BIN, updates from your server
- Backups and updatesThree things to keep, moving to a new bundle
- Work without the serverOffline vault, drafts and sync, the agent cache
How do we get the on-premises bundle?
On-premises is part of an Enterprise agreement. Once it’s signed, you receive the bundle together with its SHA-256 checksum and the release public key to check it with. Write to us to start the conversation.
Does the server need internet access?
No. Everything it needs is in the bundle, and the installer starts it in isolated mode. If you want alert email or a cloud CI system, you allow those hosts by name; nothing else is reached.
Can Crunu read our secrets on our own server?
No. Values are encrypted on people’s devices and in the agent. The server stores ciphertext, public keys and signed records, and has no key that decrypts a value. That’s the same on app.crunu.com and on-premises.
How do we update without internet access?
Carry in the new bundle, unpack it next to the old one and run its installer with the old settings. The data and keys stay. Agents then update from your server.
Can we use our company’s certificate instead of the internal one?
Yes. Give the installer your certificate and key. Caddy doesn’t renew a certificate you supply, so replace it before it expires.
Is Postgres supported?
Yes. SQLite in a Docker volume is the default; the bundle also carries a Postgres image you can choose at install.
Bring Crunu inside your network
On-premises comes with an Enterprise agreement. Tell us about your network and we’ll take it from there.