Engineering notes
Concrete choices behind reliable delivery: where boundaries sit, how failures recover, and what the system can actually prove.
Featured
Appaloft 1.4 turns Agent Workspace into a public Sandbox entry workflow: remote harnesses, collaboration leases, hibernation, and an evidence-gated path to ship. Here is the architecture, how it compares to OpenSandbox and peers, and what we are still finishing.
Appaloft's new sandbox agent runtime lets coding agents build inside isolated, expiring sandboxes, then freezes their work into immutable artifacts that only an external actor can promote. Here is where we drew the boundary.
AI agents can write an app in ten minutes. Proving what actually shipped is a harder, older problem. This is how we built Appaloft's evidence chain — and where we deliberately stopped.
How Appaloft combines a versioned keyring, short-lived OIDC credentials, plan digests, atomic migration, and an independent restore rehearsal.
A deployment needs evidence that its artifact, process, service, and public route all belong to the intended release.
Five invariants for safer single-host Docker Compose updates: image preflight, candidate verification, scoped cleanup, and explicit data boundaries.
Separate repository, CI runner, server, and deployment-state ownership—and see where Appaloft fits without pretending to manage every layer.
How Appaloft examples use explicit deployment contracts for Vite, Python, Go, and Docker Compose instead of making the platform guess.
How Appaloft turns environment copy into a plan-first workflow: topology and intent travel; databases, domains, volume data, and secret values stay behind decisions.
A failed deployment should explain where it stopped, what already happened, which actions are safe, and what verified target can be restored.
From hostname input to DNS authorization, readback, TLS, routing, and failure handling, this is how Appaloft treats custom domains as a checkable deployment workflow.
Why Appaloft generates MCP tools from the operation catalog and routes them back through the same CommandBus, QueryBus, authz, audit, and readback boundaries.
A deploy URL is part of the deployment contract: some links should never move, some aliases can move with audit, and custom domains need ownership proof.
Why Appaloft shows Blueprint installs as one readable application progress experience instead of asking users to stitch together component logs and support details.
How Appaloft thinks about GitHub Actions deployments as auditable evidence: commit SHA, image digest, config snapshot, provenance, readback, and rollback.
How Appaloft turns an agent-produced dist directory into an auditable static artifact publication instead of handing an AI broad cloud credentials.
Appaloft's lightweight Specification style in TypeScript, from selection specs to readiness gates and drift reports.
Why Appaloft separates human browser login, CI tokens, and AI agent token handoff instead of letting agents impersonate users.
Why Appaloft keeps AI skills, MCP tools, CLI commands, and the operation catalog in separate roles instead of creating an agent-only deployment path.
How Appaloft models Blueprints as versioned application topology definitions, then turns one-click deploys into reviewable dry-run install plans.
How Appaloft uses practical TypeScript value objects: schema versions, literal unions, ids, secret references, masked connections, and provider boundary aliases.
How Appaloft models InstalledApplication as an aggregate root in TypeScript, with plan acceptance, readback, failure, and rollback transitions.
How Appaloft applies domain-driven design in TypeScript through Blueprint planning, installed applications, dependency resources, and runtime composition.
How Appaloft models deployment as an auditable operating path shared by CLI, GitHub, AI tools, Blueprints, and Cloud.
A practical look at how Appaloft uses Bun for TypeScript scripts, compiled binaries, embedded Web/docs assets, PGlite, and multi-target release packaging.