A feature on the credential, checked on every request.
Only GET /health is open. Every other request presents a credential file and private key, and the credential must carry the feature for that operation. The server confirms account and credential status on each protected request through the access check your operator configured; if that check cannot be completed, it answers 503 rather than guessing. A previous success does not override a later disablement, and withdrawn credentials stay invalid.
| Feature | Grants |
|---|---|
aidc:hub:client:browse | Look up packages, versions and statistics |
aidc:hub:client:download | Download archives |
aidc:hub:admin:publish | Upload packages |
aidc:hub:admin:unpublish | Remove a package variant |
aidc:hub:client:*, aidc:hub:admin:* | All client operations, all admin operations |
Browse and download are separate: credentials that can list cannot necessarily download. A pipeline that checks its own upload needs browse and download too. Access errors can be plain text, so read the status first.
| Status | Meaning |
|---|---|
401 | No credentials reached the server, or they could not be read, or they have expired |
403 | Valid credentials without the needed feature, or an account that is disabled or no longer accepted |
503 | The server could not confirm access at that moment: a service-side condition |
The operator asks The MAIT Team for new, replacement or extended credentials; nobody can change the features of a credential file themselves. Keep the private key private and send credentials only to the server address you were given.
Every published package is signed, and clients check it before install.
When a package is published, the server checks it and signs it. Clients verify the signature and the package contents before anything is installed, and reject a package that does not match. The signing key is created on the server's first start and you can replace it on a schedule you choose; the steps are in Workflows. Back up the data volume before you change keys, and never accept a package whose verification fails.
One volume holds everything.
| Data | Notes |
|---|---|
| Published packages | The archives you publish, kept on the data volume |
| Catalogue and keys | The server's list of packages and its signing keys, on the same volume |
| Activity totals | Counts of requests and downloads, kept as indicators |
Removing the volume removes all of it, so back it up as one unit (see Operate). Outbound internet access to vendors is needed only to refresh version and vendor information: without it, published packages are still served and version discovery lists only what was published on the server. The aidc-server legal command lists the third-party components built into the executable; it covers the server, not the tools it stores.
The operator side of trust.
- Keep the server's private key and every credential private, and share the trust file freely.
- Request credentials with only the features each person or pipeline needs.
- Check each vendor's terms before you publish a tool to your AIDC Server.
- Back up the volume before upgrades, key changes and retention runs.
Limits worth knowing before you rely on it.
The server does not install anything and does not build packages; aidc-pack prepares them. Its activity totals are indicators, not an audit ledger. Health ok proves none of access, package presence or job success. Unpublishing removes a variant from distribution; activity counts survive it.