Give your teams
a path to production.
Approved ways to build, release and run applications. App Composer connects the request, the people who can authorise it, the tools that deliver it and the service you operate.
Start with a governed internal platform. Keep working services where they belong. Move a workload only when the fit, recovery and operating cost justify it.
Proposed platform responsibility model · current runtime shown separately below
- People & identityOperator sets the boundaries.
Team requests an application.Enterprise admission and current team membership - Composer in EmDashRecipe, plan & policyExact source, owning team, environment and review
- Trusted deliveryRecheck. Execute. Verify.Selected runner holds scoped credentials; the browser does not
- Application runtimeWorkers or a qualified alternativeApp-owned resources, user access and independent releases
A request crosses an authority boundary before execution. Runtime capability is separately configured; it never follows from a portal role.
The first path is deliberately small.
Current implementation scope · release proof separateThe internal-platform path connects Get Ready, Init and the native EmDash platform workspace. It plans a synthetic, small preview application on the existing ordinary-Workers deployment and keeps request/review decisions bound to the exact plan.
The first resource path is an app-owned, scoped Guestbook visitor book and a published stack page. It uses the independently deployed app’s existing database; it does not provision a new Worker or database for every request. Owner/editor/viewer permissions stay enforced. Broader knowledge recipes, production promotion, Kubernetes and strict Australian-only handling retain their separate gates.
Follow the two-team application films for the overview, technical walkthrough and their recorded local scope. Media publication status and source receipts stay with each film.
Use the current release receipt for the source, deployed runtime and actual demonstration. The public policy explorer below is a separate teaching example, not that request interface.
A platform should remove repeated work.
Proposed adoption modelA team should be able to find an approved recipe, request an application within its authority and receive a working service with an owner, operating links and a recovery path. Operators establish those boundaries once; teams inherit them.
That is useful when repeated setup, permission requests, release checks and incident archaeology slow people down. A small team with one app may be better served by direct Wrangler or Terraform. A mature platform should compare the benefit against another portal to maintain.
Adopt the model before migrating everything.
- Inventory services, owners, users, data, cost and recovery needs.
- Keep and register what works. Integrate useful existing services.
- Prove one maintained application path, then a second independently authorised team.
- Replatform, refactor or retire only with a business case and a tested exit.
Decision framework from the researched field guide. Cost evidence belongs to #170; no universal savings are established.
One operating model.
Different places to run.
Source + provider documentation Choose for the workload’s protocols, state, locality, skills and failure model. A provider-supported runtime and a qualified Composer deployment are different pieces of evidence.
| Path | Useful when | Composer evidence boundary |
|---|---|---|
| Managed Workers | Compatible web applications, APIs and event-driven work benefit from managed execution. | Current inspected runtime. This installation uses D1, R2, KV and pinned app services. Each new service still needs its own access, limits and recovery checks. |
| Workers for Platforms | A platform needs a specifically qualified user-worker dispatch model. | Separate qualification. Ordinary Workers do not establish commercial tenant admission, billing or hostile-code safety. #217. |
| celld / workerd | A controlled self-hosted Worker-compatible route merits investigation. | Candidate. Check exact compatibility, trust model, fleet ownership, ingress, durable state and recovery. It is not a drop-in guarantee. |
| EmDash on Node | A server/container deployment and suitable database/media adapters fit the operating environment. | Provider-documented route. Composer’s Access, bindings, scheduler and plugins need adaptation and independent proof. |
| EKS / AKS / GKE | The organisation needs Kubernetes workloads and already operates the cluster and its controls. | Provider mappings, unqualified here. Managed control planes still leave workload security, networking, data and recovery duties. #252. |
Hybrid is a useful first step.
A Worker can call an approved regional API while the database stays on its current platform. Private connectivity, protocol compatibility and identity must all work. Reachable TCP alone does not qualify Kafka, and an app’s private binding does not make its telemetry exporter private.
Portability needs a restore.
Redeploying code, connecting to another cloud, recovering after provider loss and active-active data are separate capabilities. A tested exit includes usable configuration, database and media export, restoration and real application behaviour.
Total cost includes engineering/on-call, minimum compute, data, backups, transfer, telemetry, security licences, migration and exit. Compare equivalent operating outcomes. A runtime entry price is not a project quote.
Sources: EmDash Node deployment, celld, celld trust model, Workers VPC, Kubernetes tenancy. Hybrid/exit qualification #253.
Policy turns a request
into an authorised action.
Illustrative explorer A plan names the team, application, environment, exact recipe/source, resources, data requirement and operating expectations. Standing policy should let ordinary supported work proceed. A real exception gets a consequential decision.
Illustrative policy · fictional organisation
Change the request. See the decision.
This teaching example runs only in your browser. It neither grants permission nor submits a request. Your platform’s trusted policy and current identity make the real decision.
Example outcome
Allowed
The current team member’s supported Workers update fits this example’s standing policy.
Next: A trusted runner would recheck identity, candidate and policy before any provider effect, then verify the service independently.
Real-world authority stays with the server and selected runner. A downloaded plan, this example and a provider acknowledgement cannot authorise a release.
Approve a candidate, then recheck it.
Accept, send back and deny belong to the current request and exact candidate. A role revoked after approval, changed source or stale evidence must stop execution. Keep builds away from deployment credentials, and use stable operation identities when a provider result is uncertain.
GitOps depends on the target.
Argo CD reconciles Kubernetes resources. Workers require an appropriate deployment/reconciliation adapter. A Git repository alone does not supply reconciliation. ServiceNow can supply change authority; it must identify the same candidate and receive the verified outcome.
Sources: Argo CD scope, Workers external delivery. Composer delivery ownership: #218, #219, #254.
Six permissions.
No accidental promotion.
Current boundaries + proposed delegation Signing in, editing content, owning a team and deploying infrastructure are distinct powers. Enforce them again at the API and execution boundary. A team identifier from a browser is a selector, never proof of membership.
| Domain / owner | Controls | Boundary to preserve |
|---|---|---|
| Enterprise identityIdentity provider / admission operator | Who can enter; MFA, sign-in, offboarding and active sessions. | Cloudflare Access protects this installation. Workspace invitations alone do not admit a person. |
| EmDash administrationCMS administrator | Which native CMS and plugin controls a signed-in person can use. | Native admin permissions remain required; a public visitor has none. |
| Composer authorisationWorkspace / platform operator | Which team, app, request and operation this person may control. | Existing owner/editor/viewer membership is distinct from proposed broader delegation. |
| Delivery identityTrusted runner / cloud account owner | Which resource or deployment effect may happen in the selected environment. | A spec, receipt or approval does not supply cloud credentials. |
| Runtime capabilityApplication deployment owner | Which databases, buckets, services and secrets the running app can use. | Bindings need explicit scope; a portal role cannot create one. |
| Application usersIndividual application owner | Who may use the resulting service and access its business records. | Application login does not make someone a Composer operator. |
For offboarding, test admission denial, current Composer membership and already active sessions. Group mapping, SCIM and custom roles should appear as supported only after that exact configured path is exercised. An invitation is neither admission through Access nor a global infrastructure grant.
Sources: inspected workspace access, EmDash authentication, Workers roles. Self-service/IAM #257.
Keep the service’s story
with the service.
Proposed complete lifecycle - Request Owner, environment, exact recipe and resource plan.
- Authorise Current actor, policy, candidate and any necessary exception.
- Deliver Scoped runner, stable operation identity, adopted/created resources.
- Verify & operate Independent health, release lineage, usage, runbook and incident owner.
- Recover & retire Compatible rollback, tested data/media restore, export and retention.
Preparing, waiting for a decision, running, verifying, complete and needs attention should describe real work. An unavailable local runner is pending; it is not an always-online hosted runner. A provider accepting a deployment is not evidence that its service works.
Code rollback does not rewind records, restore deleted media or reverse a payment. Keep those recovery procedures separate. Preserve each independent app’s source, settings and data ownership throughout updates and retirement.
Lifecycle delivery: #219; operating evidence: #220; recovery: #118.
Connect the tools
your organisation uses.
Provider-documented / proposed connections These are researched integration contracts. They are not a claim that all fourteen Composer adapters exist. Version, entitlement, authentication, network path, data handling, authority and failure behaviour must be qualified for the actual installation.
- HashiCorp Vault
- Lease credentials to a trusted runner; renew or revoke them deliberately.
- Ansible Vault
- Encrypt playbook files and variables at rest; unlock only in the authorised execution environment.
- Snyk
- Scan the exact candidate; distinguish policy findings from failed or incomplete scans.
- Splunk
- Receive selected telemetry through a qualified ingestion path and monitor delivery.
- OpenSearch
- Index telemetry through an assessed collector / Data Prepper pipeline.
- ClickHouse
- Query application events; keep ingestion credentials, schema and retention explicit.
- Kafka
- Bridge events through a compatible gateway; inspect per-record failures after HTTP acceptance.
- Jenkins
- Run a trusted delivery job; isolate untrusted builds from deployment credentials.
- Terraform
- Plan and apply declared resources with scoped providers, state locking and one owner per property.
- Ansible Playbooks
- Configure suitable hosts through an authorised runner; check mode has module-specific limits.
- ServiceNow
- Bind a change decision to the service, exact candidate and verified outcome.
- PagerDuty
- Keep deployment/change events separate from incident trigger, acknowledgement and resolution.
- Wiz
- Assess documented DNS/exposure and AI endpoint coverage; verify each desired resource type.
- Argo CD
- Reconcile Kubernetes desired state; use a separate delivery adapter for Workers.
A Vault server, Kafka broker, Jenkins controller or arbitrary Ansible process belongs on a suitable runtime. Workers may integrate through bounded APIs; they do not become those server processes.
What an operational connection must prove
Bind owner, app, environment, release and operation identities; scope credentials server-side; document the receiver and private/public network path; minimise and redact data; handle duplicates, partial responses, timeouts and ambiguous completion; monitor delivery and retain a recoverable outcome.
Workers documents OTLP export for logs and traces with a metrics limitation. Sampling is not a complete audit record. Private application connectivity does not establish private exporter reachability. Retention and persist:false do not prove whole-platform residency.
Workers OpenTelemetry export. The Agentic Responder / PagerDuty demonstration has its own incident and recovery evidence; this guide does not qualify that provider execution.
Read the current connector contracts and local adapter evidence · Original sourced integration catalogue. Connector qualification #255.
“Australian hosted”
needs a data-flow answer.
Provider-documented limits · reviewed 23 October 2026 Map each path before promising Australian-only handling. Execution, database storage, media, telemetry, code/secrets, support and subprocessors can have different locations and guarantees.
- Code & secrets Still deployed globally. Background triggers and outgoing subrequests have separate caveats.
- D1 & media Location hints do not guarantee Australian storage. Check each product’s jurisdictions.
- Telemetry & support No Australian Customer Metadata Boundary option is listed. Assess exporters, support and subprocessors separately.
| Path | Documented position | Consequence |
|---|---|---|
| Workers HTTP | Regional Services restricts execution and TLS termination on the configured custom domain; other triggers and subrequests have exclusions. | Regional processing is not a whole-system residency guarantee. Workers regionalisation. |
| Regional metadata | Australia is listed for Regional Services; Customer Metadata Boundary lists EU and US. IRAP Protected can include locations outside Australia. | Do not equate assessment scope, Australian execution and Australian-only metadata. Region support. |
| D1 | Jurisdictions list EU, US and FedRAMP. An Oceania hint is not a guarantee. | Australian-only database storage is not substantiated by a hint. D1 location. |
| R2 | Location hints are best effort; jurisdiction restrictions are a separate guarantee. | Inspect the required jurisdiction, backups and media access path. R2 location. |
For a strict Australian-only requirement, the generic all-Cloudflare design is not established. Keep that requirement intact. Assess a controlled regional backend, plus its ingress, backups, telemetry, support access, contracts and external APIs.
Open provider-documentation conflict
The Workers configuration guide and product-compatibility table differ on Customer Metadata Boundary with workers.dev. This guide makes no support claim for that combination. Resolve it with the provider before relying on it. Compare the compatibility table.
Supplier evidence is
the beginning of assurance.
Assessment guidance · no certification claim SOC 2 has a defined scope.
Obtain the supplier’s current report and relevant bridge letter. Match services, period, exceptions and customer controls to the actual design. A supplier examination does not attest to Composer’s authorisation, release process or your support operation.
IRAP is an assessment.
Read the actual report and tested controls. ASD states that assessors do not accredit or endorse systems, and completing an assessment does not establish compliance. The customer still owns its system acceptance decision.
For Australian work, assess applicable Privacy Act / APP 8 cross-border handling, APP 11 protection/retention, Notifiable Data Breaches, ISM/ASD Essentials and sector requirements such as APRA CPS 230/234. Applicability depends on the organisation, data and service. This reference does not make that determination.
Useful evidence names a control owner and includes access/revocation tests, exact change samples, vulnerability handling, incident exercises, isolated restoration and supplier/exit review. A Wiz finding or a scan badge contributes evidence; neither certifies the application.
Primary guidance: APP 8, APP 11, Essentials for cloud, CPS 230, CPS 234. Assurance ownership: #256.