Elizon Docs
Guides & Walkthroughs

Sharing across Organizations

Sign once, install into many Organizations, such as a services firm's clients.

A common pattern: you build a Package once, in your own Organization, and install it into several other Organizations, perhaps each client's own Elizon. Signing and trust make that work without a central registry.

Installing into your own Organization

If you sign with Organization A and install into A, there's nothing extra to do. An Organization always trusts its own signing keys, current and past.

Installing into another Organization

When Organization B installs a Package signed by A, B has to decide to trust A's key. Verification reports PKG_UNKNOWN_SIGNER_KEY until it does. That isn't a sign of tampering; it's B's way of asking "whose key is this?".

B trusts A by adding A's public-key document, a small JSON file of type elizon.signing-public-key.v1 that carries the key, its id and A's name:

  • In Studio: on the Review step, choose Add signer's public key and select the file. Only add a key file you received from the signer through a channel you trust.

  • With the CLI: pass --trust=<file>:

    npx @elizon/cli install triage-1.2.0.pkg --target=client-b --trust=./acme-signing-key.json --yes

Export your public key

On a machine connected to your Organization (A), write its public key to a file:

npx @elizon/cli target key --out=acme-signing-key.json
✓ wrote the signing public key to /home/you/acme-signing-key.json
  ed25519:4f2c9a…  Acme Ltd

Send that file to each client. It contains public keys only, but send it over a channel the client trusts: whoever controls the file decides whose Packages the client will accept. If your Organization has signed with more than one key over time, --all writes every key as a list, which --trust accepts (Studio's Add signer's public key takes a single key).

Checking what's trusted

After verifying, Studio and the CLI both show who signed the Package:

Self-signed by "Acme Ltd" (key ed25519:4f2c…). The name is the signer's own claim; no registry has counter-signed this Package.

The name is whatever the signing Organization calls itself. What makes the key trustworthy is how you got the key file, not the name inside it.

One Package, many clients, from CI

Connect one target per client Organization, then install in a loop. See the install example and CI/CD.

Add --activate (and, for Packages with an evaluation suite, --acknowledge-evaluation) so each client's Package goes live in the same run.