A small, inspectable system for records that must be trusted.
Corenil uses conservative infrastructure choices to keep the operational record clear, private, and auditable. The design favours simple components, strong database rules, controlled access, and deployment boundaries that can be explained to both managers and technical caretakers.
Architecture in plain terms
Corenil separates the durable record from the interface around it. The database holds the rules and history. The web layer exposes controlled actions. The user interface remains thin enough to inspect and replace without disturbing the record.
Database first
PostgreSQL stores the operating facts, permissions, audit trail, workflow state, ledger records, and control views. The database is treated as the guarded record, not as a passive storage box.
JSON backend
Corenil exposes operational endpoints under /api/. These return structured JSON so the interface can remain simple, testable, and separate from business rules.
Thin HTML interface
The browser pages under /ui/ render management views, dashboards, workbenches, and control consoles by calling the JSON endpoints.
Small executable units
The web actions are intentionally narrow. Each program or endpoint should be understandable, reviewable, and limited to the work it exists to perform.
Controlled authentication
Authenticated access is required for operating areas. Credentials and roles are connected to the permissions needed for the work being performed.
Operational dashboards
Readiness, reconciliation, inbox work, trial balance, recent journals, supplier control, daily close, and exception dashboards make system condition visible.
The goal is not to hide complexity behind fashion. The goal is to reduce unnecessary complexity until the record can be trusted.
Corenil is intentionally built from stable parts: OpenBSD, PostgreSQL, C, JSON, HTTPS, firewall rules, and a small browser interface.
This does not mean the system cannot grow. It means growth should happen through clear modules, controlled endpoints, and records that remain explainable as the organization expands.
Deployment model
A Corenil deployment is best understood as one controlled node per organization. This keeps records close to the people accountable for them while allowing the same proven pattern to be repeated across many clients.
| Layer | Recommended approach | Reason |
|---|---|---|
| Host | Dedicated OpenBSD machine managed by the organization or trusted technical caretaker. | Keeps the node inspectable, stable, and separated from unnecessary shared infrastructure. |
| Database | PostgreSQL bound to 127.0.0.1. |
The database should not be exposed directly to the network. |
| Web access | HTTPS through OpenBSD httpd, slowcgi, and controlled routing. |
Keeps the web surface small and understandable. |
| Remote users | Prefer VPN access into the organization’s network. | Remote work remains possible without treating the whole system as a public internet service. |
| Public exposure | Only where necessary, using HTTPS, firewall rules, rate limits, and restricted endpoints. | Public access should be deliberate, narrow, and logged. |
| Scaling | Scale by repeating controlled nodes for separate organizations. | Corenil grows globally through disciplined replication, not by forcing every client into one giant shared system. |
Security boundaries
Corenil’s security posture is based on reducing exposure, separating administrative access from user access, and ensuring important actions leave evidence.
Network boundary
- Private node by default.
- VPN preferred for remote use.
- No plain HTTP for authenticated work.
Database boundary
- PostgreSQL remains local to the node.
- Application actions call controlled database functions.
- Permissions are checked before sensitive work is done.
Operating boundary
- End users do not need SSH.
- Administration is separate from daily operation.
- Firewall rules define what is reachable.
Audit boundary
- Approvals and changes are recorded.
- Exceptions are visible for review.
- Daily close checks expose unresolved work.
Code boundary
- Small programs are easier to review.
- Endpoints should do one clear job.
- Plain formats make testing easier.
Data boundary
- The record belongs to the organization.
- Exports and backups remain part of the operating discipline.
- History should not depend on vendor memory.
Why CGI-style execution is acceptable here
Corenil is not designed as a public social network or advertising platform. It is a private operating records system serving defined users within controlled organizations.
Clear process boundary
Small request handlers reduce shared state and make failures easier to isolate.
Suitable traffic profile
Most client nodes serve dozens or hundreds of operational users, not millions of anonymous public visitors.
Path to evolve
If a deployment outgrows this model, the business logic can remain while the transport layer moves to persistent workers or another controlled service pattern.
Measured technology for records that carry responsibility.
Corenil uses simple parts deliberately: not because simple is old, but because records that matter must remain understandable, inspectable, and repairable.