@eliware/infrastructure-template 
- Features
- Requirements
- Setup
- Usage
- Development
- Testing
- Troubleshooting
- Security
- Managed targets
- Configuration
- Desired state
- Validation
- Change boundaries
- Support
- License
- Links
This template owns reusable infrastructure repository structure; each derived repository owns its platform-specific desired state and change boundaries.
Package description: An Eliware infrastructure repository template for desired state, validation, rollout, and rollback boundaries. Author: Eliware eliware@eliware.org. License: MIT.
An Eliware infrastructure repository template for desired state, validation, rollout, and rollback boundaries. It provides an indexed desired-state surface and shared Node.js repository validation.
Use Node.js 26 and npm. The template is private and must remain private.
Create a private repository from this template, replace its package identity and repository URLs, then run npm ci. Add the desired state and deterministic checks for the managed infrastructure.
Use desired-state/ for committed declarative inputs. Define the managed targets and environments in a derived repository; this template does not include live infrastructure configuration.
Read AGENTS.md, specs/README.md, and the applicable shared conventions before changing the template. Keep repository-specific requirements in specs/directives.yaml.
Documentation: specifications
Run npm test for aggregate repository validation through eliware-test. CI runs npm ci followed by npm test. Add infrastructure-specific deterministic validation when a derived repository defines the corresponding manifests and schemas.
If validation cannot find Node.js or npm, install Node.js 26 and run npm ci. A passing repository check does not prove that deployed infrastructure is healthy.
Keep the repository private. Do not commit plaintext secrets, credentials, decrypted runtime state, or live-only state. Encrypted secret payloads may be committed. Review committed inputs for secrets even when they are encrypted.
A derived repository must identify each managed platform, environment, purpose, and ownership boundary. No live target is configured by this template.
The template has no runtime configuration or environment variables. Package metadata and .knit/deploy.yaml configure repository tooling and synchronization; they are not runtime settings.
Keep committed declarative configuration and deployment inputs in desired-state/, organized by managed target and environment. Keep live runtime evidence and canonical operating procedures in the owning Operations or workspace repository.
Run deterministic syntax, schema, reference, render, and safety checks for the desired state present in a derived repository. Keep platform-specific preflights in that repository. A successful render or repository validation does not prove live infrastructure health.
Document promotion and rollback procedures in the owning Operations or workspace repository and link to them here. Do not treat a commit, validation pass, or render as authorization to deploy.
For help or discussion, join the Eliware community:
