Connected application hosting

Status: accepted controlled connected-hosting profile in the step 4 ledger. The step 5 runtime and relocation guide describes the newer Shared implementation and its separate acceptance evidence. A complete autonomous platform installation is not claimed.

Owners and supported inputsCopy Anchor Link

The Go deployment coordinator uses the existing scoped metadata, operation leases, outbox and native pg-boss delivery. The runtime agent owns BuildKit builds, immutable artifacts, native application processes and retained assets. The routing controller configures exact authorized names in Caddy. GitHub supplies verified source/check results. Frameworks supply native build/development commands. They do not implement another deployment process.

The portable manifest is deliberately small:

{"version":1,"framework":"next","database":{}}

framework accepts auto, next, vite or the validated dockerfile production alternative. database.initializationRef optionally identifies an operator registered, versioned safe Preview dataset. The manifest grants no authority and contains no installation addresses, credentials or implicit Production selection. Next.js 16.4.3 and Vite 8.3.5 are the current framework pins. See the compatibility decision.

Hosted Preview startupCopy Anchor Link

Build api/cmd/astrogate-dependencies with the supported Go toolchain. Its protected target JSON selects Origin, CAFile, TokenFile, Tenant, Project, Environment and initial ExpectedRevision. Credentials and trust anchors are installation inputs, separate from application source.

astrogate-dependencies -mode start \
  -project /absolute/application \
  -target /private/preview-target.json \
  -source-revision EXACT_CHECKED_GIT_SHA \
  -output /private/resolved-startup.json \
  -deadline 3m -poll 250ms -response-bytes 1048576

These example observation/envelope budgets belong to the disposable integration profile, not public tenant limits. Select installation budgets from its supported workload and response envelope. In an installation with placement policy, establish the ready environment allocation through the placement API first. An unplaced workspace start is rejected without a persisted operation; it cannot block the initial placement behind its own waiting startup.

The command validates astrogate.json, resolves or reuses only its declared Preview database, probes readiness, starts/reuses the workspace through the existing API and returns its protected HTTPS URL. Repeated starts reuse the same identity, source volume and checkpointed image.

Use -mode status to observe and -mode stop to stop the workspace. Stop retains source and data. An existing workspace with another initial source SHA requires an explicit replacement decision. Ordinary stop/start does not rebuild from a new branch head, replay initialization or overwrite edits. Mutable workspace writes use management.workspaces.write and expected environment revisions. Only Preview admits mutable development processes.

Local application with an explicit hosted Preview databaseCopy Anchor Link

The same command accepts -execution local -local-config /private/local.json. This supported Unix developer profile runs developer-owned source in the foreground. It is distinct from admitting hostile hosted tenant code. The approved rehearsal runs it as a separate unprivileged Unix account on disposable execution capacity, never on permanent management or database capacity.

The local installation configuration selects NodeDirectory, NodeVersion, ProfileFile, StateDirectory, SessionIssuerTokenFile, Port, UpstreamPort, DrainMS, RevalidationMS and RequestTimeoutMS. Source dependencies must already be installed with the reviewed lockfile/toolchain. The command does not silently install privileged software. The pinned framework command is shared with managed workspaces; the local listener binds only the exact loopback port. A private Unix socket/lock owns start/status/stop, and a conflicting port never authorizes terminating another process.

The API still resolves and probes the explicit Preview dependency before the application starts. A separately registered, app-scoped session issuer stays in the launcher. The local gateway validates the user's native authority cookie through the remote session bridge, supplies only a per-user database session to SSR and the browser, and removes the authority cookie before proxying app code. Ordinary application imports never receive issuer or infrastructure credentials. Stopping one local application cannot stop another application's data engine.

The database installation must explicitly admit each loopback browser origin in LocalOrigins. Only HTTP origins with a literal loopback address and explicit port are accepted there. Hosted Origins retain HTTPS. Secure authority cookies and browser trust still apply; this is not a public HTTP deployment profile. The rehearsal uses Chromium's trustworthy loopback handling. An offline engine bundle, arbitrary desktop OS compatibility and a complete identity login UI remain separate acceptance claims.

Native updates and failuresCopy Anchor Link

Next.js uses native Fast Refresh where supported. The minimal Vite fixture uses native full-document reload for entry-module edits. Schema/rule changes remain explicit reviewed native plans; they are not HMR. Framework compile errors are visible in native development output. A listening HTTP process does not prove that every module compiled successfully.

Immutable releases freeze source, profile, public bindings, database identity and reviewed schema/rule plans. A new candidate starts beside the active release, passes readiness, switches the route and drains in-flight requests. Compatible code rollback selects retained artifact bytes; it never reverses database data or pretends raw build logs are a recovery artifact.

Custom Dockerfile outputCopy Anchor Link

The same source/check/build/activation controller accepts the registered dockerfile profile. Use the verified native Dockerfile frontend and immutable base image required by that execution profile. Explicit public environment bindings are native build arguments; they must never contain credentials. Build arguments are not a secret transport.

For public static assets served at the URL root, the image can declare LABEL io.astrogate.static-assets="/home/node/app/dist". The path must be a canonical absolute directory below the image root. The common runtime owner validates and retains those bytes alongside the immutable release, preserving old browser asset URLs during updates. Omit the label when the image has no such public asset directory. Do not label private source or server files as public assets. This is native image metadata, not a second deployment engine.

A capacity refusal is actionable. Preserve the old release and inspect physical RAM, runtime reservations, disk, native Docker address pools and the selected profile. Native cache collection removes obsolete worker reservations while preserving workspace source/current caches. It does not delete application data or force-remove referenced images. BuildKit invalidates compiled layers from changed inputs within a cache scoped by environment, trust and runtime profile.

See recovery, the deployment guide, database usage and the canonical routing contract.