111k

Deployment

The Topoo Cloud module that turns a Project and its Nodes into a configured, versioned, running, and operable system.

Deployment is the first functional module of Topoo Cloud.

It owns the path from a Project's source and structure to an accepted release running in an Environment. GitHub supplies canonical source and document history, and Cloudflare or another infrastructure provider may supply runtime capacity. Topoo owns the customer-facing Project model and the control path that connects them.

Module structure

AreaResponsibility
ProjectThe complete product, integration boundary, environments, domains, release authority, and operating state.
NodeA permission-scoped code container that divides attention and responsibility inside a Project.
Work Sessions and Local RuntimeOne task per external Session, Project-scoped Node permissions, isolated local Workspaces, automatic Checkpoints, and integration.
Node Workbench and EditorsThe common editing surface plus code and specialized editor modes for a Node.
Source and GitGitHub repository bindings, immutable Topoo Source Revisions, source provenance, document revisions, and change delivery.
Runtime and ResourcesExecution capacity, persistent resources, bindings, and truthful operating state.
P35 Shadow Migration PilotFirst online acceptance project for a Topoo-managed application copy, resources, migrations, combined Artifact, and independent Preview.
Release ControlIntegration, validation, artifacts, Preview, Production promotion, and rollback.

Canonical relationship

Project
├── Nodes
├── Work Sessions
│   └── Session Node Scopes and isolated Workspaces
├── Source and Git
├── Configuration and Secrets
├── Runtime and Resources
├── Environments and Domains
├── Releases and Deployments
└── Observability and Audit

Project is the complete product and final release authority. Nodes divide that Project into bounded code containers that people, teams, and Agents can work on under different permissions. Work Sessions represent temporary tasks and may link to one or more Nodes. A Node can be edited and versioned independently, but it remains part of the Project and does not gain independent Production authority.

Provider boundary

GitHub / Git provider
→ source and version input
 
Topoo Cloud
→ Project, Node, Work Session, permissions, integration, release, and operations control plane
 
Topoo Local Runtime
→ isolated local Workspace, Agent process cwd, Checkpoints, and command execution
 
Cloudflare / infrastructure provider
→ runtime, network, storage, and execution capacity

Topoo depends on GitHub for canonical editable source and document history without turning Repository, Branch, Pull Request, or Commit into the Topoo product model. Topoo may retain immutable source snapshots and isolated Session Workspaces for build, redeploy, rollback, and Agent safety, but it does not expose a second Git authority. Continued versioned editing requires a GitHub repository binding.

The same boundary applies to runtime infrastructure: customers configure Topoo Runtime, Database, Storage, Cache, AI, Domain, and Deployment. Topoo privately invokes upstream provider adapters and keeps their credentials, product identifiers, and execution APIs outside the customer workflow.

Documentation status

These pages combine three kinds of information:

  • Canonical product model — terms and boundaries that the documentation adopts.
  • Implementation evidence — behavior confirmed in current code or a verified runtime.
  • Target capability — planned behavior that must not be presented as already complete.

Use Source Implementation Status for the current audited source-control boundary.