Skip to main content
Tesslate OpenSail

​
What it is

The Architecture Panel is a visual node-graph canvas where you design, wire, and manage the full topology of a project. Every project has one. It is the single source of truth for what your app is: which containers run, how they connect, where secrets flow, where it deploys. Under the hood it is a React Flow canvas backed by .tesslate/config.json. Both humans and agents read and write the same file. When the agent adds a Postgres container and wires its DATABASE_URL into the backend, new nodes and edges appear on the canvas in real time. When you drag a new service onto the canvas, the agent sees the updated graph on its next iteration. One file, two authors, no drift.

Visual authoring

Drag, drop, connect. No docker-compose YAML to hand-edit.

Agent co-author

Agents call apply_setup_config to mutate the graph through the same schema.

Typed graph

Parseable, roundtrippable, versionable. Agents reason over structure, not prose.

Publish-ready

The manifest you publish as an app is a serialized snapshot of this graph.

​
Node types

Every node on the canvas is one of four types.
Your app containers (frontend, backend, workers). Color-coded by role:
  • Green base (user application code)
  • Blue service (Postgres, Redis, MySQL, Mongo, MinIO)
  • Purple external (Supabase, Stripe, SendGrid)
  • Cyan hybrid
Each shows status (running, stopped, starting, error), port, and tech stack. Click to open the properties panel. Double-click to jump into the code editor.

​
Edge types

Edges express different kinds of dependency. Each has its own color and animation so the graph stays readable as it grows.
Edge typeColorStyleMeaning
env_injectionOrangeDashedSource container’s exports become target’s env vars
http_apiBlueSolid, animatedHTTP service dependency
databaseGreenSolidPersistence dependency
cacheRedDashedRedis or memcached
browser_previewPurpleDashedContainer to preview window
deploymentOrangeDashed with arrowContainer to deployment target
agent_invokesGraySolidHosted agent to service dependency
Draw an edge by dragging from any of a node’s four handles to another node. The canvas validates connection compatibility (preview nodes accept one incoming, deployment targets accept only static and server containers, and so on).

​
Why a graph

The AI agent needs a structured, parseable, roundtrippable target. If “what are the containers and how do they connect” lives as free-form prose in chat, every edit requires re-inferring state. The panel gives both humans and agents a typed graph they can read and write. Benefits stack up:
  • Credentials and secrets are visible as env_injection edges, not buried in .env files
  • Multi-container topology is first-class instead of hidden inside docker-compose YAML
  • Previews are explicit nodes so you always know what the iframe is pointing at
  • Deployments are explicit nodes so A/B deploys are a drawing, not a config change
  • Publishing serializes the graph into the app manifest so install restores the same graph into a new project

​
Editing

Three surfaces mutate the graph:
1

Drag and drop on the canvas

Pull a node from the Marketplace sidebar. Draw edges with the mouse. Reposition nodes. All changes persist to .tesslate/config.json through the sync_project_config pipeline.
2

Container Properties Panel

Click any container node. The right-side panel opens with name, image, port, env vars, and startup command. Save and the graph updates.
3

Agent calls

Agents mutate the graph with the apply_setup_config tool. This validates every startup command, upserts Container rows, full-replaces ContainerConnection, DeploymentTarget, and BrowserPreview records, and writes the file. All in one transaction.
Never edit .tesslate/config.json through write_file. Writes through write_file skip container sync, swallow validation errors, and drift the database out of sync with the file. Always use apply_setup_config.

​
Auto-layout

The canvas auto-lays nodes on initial load using Dagre (left-to-right). Click Auto Layout to re-apply after big changes. Node sizes are hinted: containers 180x100, browser previews 320x280, deployment targets 220x120.

​
Canvas powers

  • Pan and zoom with cursor-anchored math so the point under the cursor stays fixed
  • Snap guides auto-align nodes as you drag
  • Lock toggle prevents accidental edits while navigating
  • Theme-aware styling uses var(--surface), var(--text) so the graph adapts to dark/light and custom themes
  • Memoized nodes and edges keep rendering smooth even on 50+ node graphs

​
Relationship to apps

When you publish a workspace as an app, the Architecture Panel’s graph becomes the app’s manifest. Containers, connections, deployment targets, and hosted agents all ship together. When someone installs your app, the install saga restores the graph into a new project with their volume, their credentials, and their billing configuration. One edit to the canvas in the source workspace is one diff in the next version.

Projects

The project that owns the graph.

Live preview

Preview nodes on the canvas.

Deployment targets

All 22 supported targets.

Publishing apps

Serialize the graph into a manifest.