AutoCore Host Security Boundary
Defines host-owner responsibilities without publishing private infrastructure details.
The host is outside the application repository's complete control. Operators own operating-system updates, SSH policy, firewall and exposed ports, time synchronization, disk capacity, container runtime, host logs, and emergency access.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Network | Expose only the intended edge and application ports; keep PostgreSQL, Redis, and Meilisearch private. |
| Access | Use named administrative access, least privilege, key rotation, and a tested break-glass path. |
| Patching | Track operating-system, container-runtime, image, and dependency updates as separate maintenance work. |
| Capacity | Monitor disk, memory, CPU, log growth, and backup space before they become outages. |
| Privacy | Do not place real hostnames, IP addresses, provider accounts, or private runbooks in public docs. |
High-risk operation
Use explicit authorization, a written reason, a confirmation gate, and post-action verification. Documentation does not grant permission to change a deployment.
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.