AppCore Runtime

AppCore is not an app. It is the reusable runtime layer I built so future local-first applications do not have to reinvent lifecycle, manifests, storage, security, sync, supervision, peer RPC and update infrastructure.

The problem

Local-first applications keep accumulating the same infrastructure problems:

• how to describe an application without hard-coding deployment details;
• how to change from a local notebook to a cluster without rewriting business code;
• how to run commands, queries, background services and updates consistently;
• how to store data locally while keeping formats versioned and recoverable;
• how to sync conservatively without pretending to be a multi-master database;
• how to keep security boundaries visible instead of implicit.

AppCore exists because these problems should not be solved again inside every business application.

The contract

The 1.0 contract reduces a new application to three architecture artifacts:

1. application.toml for portable application identity and requirements.
2. deployment.toml for installation-owned providers, paths, network and secret references.
3. Business code implementing appcore_bin::application::Application.

The runtime owns the infrastructure decisions behind those artifacts. Changing the deployment profile should change the deployment manifest, not the business logic.

Architecture

External application
  -> appcore-bin facade
  -> API, core and managed runtime services
  -> provider implementations
  -> contracts and foundational types

The important rule is vocabulary control. Runtime crates must not contain a product, company, customer or domain-specific concept. Business rules, product integrations and customer configuration belong outside AppCore.

Module map

The runtime is split by responsibility:

make architecture.check enforces dependency, vocabulary, module-size and module-map rules. That is a signal about the way the project is written: architecture is not a diagram in a README; it is a gate.

Decisions and trade-offs

AppCore intentionally does not provide RAFT, multi-master data, OAuth, an embedded production vault, a general database engine, inbound TLS termination or business workflows. Those are not omissions hidden behind roadmap language. They are boundaries.

The runtime accepts only V1 manifests, protocol 1, /v1/* HTTP routes and V1 persistent formats in the RC line. Removed inputs are rejected instead of being converted silently.

Security model

The runtime protects infrastructure contracts. The deployment protects host, network, inbound TLS, operating-system account and production secret backend. The application protects business data and authorization.

The implementation reflects that split:

• manifests contain secret references, not secret payloads;
• filesystem providers validate paths and reject traversal;
• DNT sealed storage resolves keys externally and protects files against offline inspection and tampering;
• peer envelopes bind protocol, tenant, cluster, origin, target, expiry, nonce, trace and payload hash;
• update artifacts are signed by default in production profiles.

What was hard

The hard part was not writing a crate named sync or security. The hard part was keeping the runtime from becoming a business framework. Every useful capability risks pulling domain vocabulary into the foundation. AppCore's answer is layering, manifests, provider boundaries and explicit non-goals.

What I learned

The project clarifies my engineering style:

• freeze contracts before adding convenience;
• document what the system refuses to do;
• make examples executable conformance fixtures;
• treat release readiness as evidence, not optimism;
• keep operational failure modes visible to the deployer.

AppCore is the portfolio's central case because it shows architecture under pressure: not a screen, not a demo, but a reusable foundation for applications that have to keep working locally.

2026 © Daniel Netto. Todos os direitos reservados.

Hospedado por Verceldnetto.dev