Featured post
How Appaloft applies domain-driven design in TypeScript through Blueprint planning, installed applications, dependency resources, and runtime composition.
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.
How Appaloft Deployment Proof compares deployment intent with runtime readback, and why a green job or HTTP 200 is not enough.
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 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.