Deploying and Monitoring

Once you’ve built your Compose App and tested it locally, deploy it. Your app runs in an isolated runtime environment with a dedicated database. Environment variables and secrets you’ve provided are available to your app, and the durability engine resumes task execution across restarts and rolling deploys. You can monitor your app via the Goldsky webapp.

The `deploy` command

Deploy by running this command with a reference to your manifest file. The command is idempotent: it upserts your app to the cloud.

goldsky compose deploy

Your manifest must include an api_version field to deploy. This pins your app to a specific Compose runtime. Use "stable" if unsure. See Release channels for details.

The Compose CLI extension provisions the necessary resources and launches your app based on your manifest. Once complete, cron tasks start and HTTP triggers become available. See Task triggers for more information. On success, deploy prints the URL of your app’s dashboard.

Hosted Postgres database

When you deploy, Compose automatically provisions a dedicated Postgres database for your app. This database is used for two things:

Your state. Any collections you create in your tasks are stored here. You can query or inspect your own data directly.
Compose internal state. Compose uses the same database to power durable execution (resuming tasks cleanly after crashes and rolling deploys), reorg monitoring for transactions, and wallet bookkeeping. These internal tables live in reserved namespaces and are managed by the runtime.

Because your app has its own database, your data is isolated from other apps and from Goldsky’s own systems.

Monitoring your app via the webapp

Like with our indexing products, you’ll see your Compose Apps in the Goldsky webapp. From there you can view the app’s status, recent task runs (with per-operation details: each ctx.* call a task made), and raw log output. The URL for your app’s dashboard is:

https://app.goldsky.com/{projectId}/dashboard/compose/{appName}

Viewing and downloading deployed source

When you deploy, the CLI uploads your app’s full local source tree: the transitive local import closure, package.json and lockfile, tsconfig.json, and everything under src/contracts/. node_modules, .env*, and files that look like keys or secrets are excluded. The dashboard’s Code tab is a file browser over that source tree. The Download app button produces a zip that is a runnable local Compose project, including a names-only .env.example. Apps deployed before source capture existed show per-task compiled bundles instead of original sources. Redeploy with a current CLI to get full fidelity. Very large projects may skip source capture, in which case the CLI warns at deploy time and the dashboard falls back to the same per-task bundles. The CLI equivalents are goldsky compose source and goldsky compose download; see App lifecycle for the workflow.

Managing a deployed app from the CLI

For day-to-day app management from the terminal, use the lifecycle commands:

goldsky compose status   # runtime status
goldsky compose list     # all apps in your project
goldsky compose logs -f  # tail logs
goldsky compose pause    # stop triggers without deleting state
goldsky compose resume
goldsky compose delete   # delete the app (and optionally the database)

Deleting a Compose app

You can delete a Compose app either from the webapp (navigate to the app’s dashboard and click Delete) or from the CLI:

goldsky compose delete

Both paths require you to type the app name to confirm. See App lifecycle for CLI flags.

Database management options

When deleting a Compose app that uses a hosted Postgres database, you can choose whether to keep or delete the associated database:

Delete associated database: The hosted Postgres database will be permanently deleted along with the app and all its data. This is the default in the webapp modal (“Delete associated database” is pre-checked). From the CLI, pass --delete-database or answer the interactive prompt to opt in.
Keep database: Preserve the database when deleting the app. This is useful if you want to retain your data for analysis or migrate it to another app. This is the default in the CLI; in the webapp, uncheck “Delete associated database” before confirming.

Database deletion is permanent and cannot be undone. Make sure to back up any important data before deleting.

Pipeline validation

If you choose to delete the associated database, Compose checks whether any active pipelines use it. If one or more pipelines reference the database, deletion is blocked and the error message lists the affected pipelines. To proceed with database deletion in this case, you must first:

Delete or modify the pipelines that reference the database
Then retry deleting the Compose app with the database option selected

Alternatively, uncheck the “Delete associated database” option: the app is deleted but the database stays available to the existing pipelines.

Compose

Solutions

Guides

Reference

The `deploy` command

Hosted Postgres database

Monitoring your app via the webapp

Viewing and downloading deployed source

Managing a deployed app from the CLI

Deleting a Compose app

Database management options

Pipeline validation

​The deploy command

​Hosted Postgres database

​Monitoring your app via the webapp

​Viewing and downloading deployed source

​Managing a deployed app from the CLI

​Deleting a Compose app

​Database management options

​Pipeline validation

The `deploy` command

Hosted Postgres database

Monitoring your app via the webapp

Viewing and downloading deployed source

Managing a deployed app from the CLI

Deleting a Compose app

Database management options

Pipeline validation