Apso Cloud

Apso Cloud deploys a linked generated service and its database resources. Use it when your team wants the schema, repository connection, credentials, environment variables, API docs, deployment status, and logs available from one service workspace.

Before deployment

You need:

An Apso account and workspace
A local project with .apsorc
A linked Apso service
A connected GitHub account
A repository available for the generated source

The exact operational views available in the dashboard depend on the service plan and deployment mode.

First deployment

Authenticate and link


apso login
apso use your-workspace-slug
apso link --workspace your-workspace-slug --create project-api

Use --service project-api instead of --create when the service already exists.

Connect GitHub


apso github connect

Complete the browser authorization flow while signed in to Apso Cloud.

Validate the source


apso schema validate
apso generate
apso migrate

Run the generated framework tests and build before deploying.

Deploy


apso deploy --repo your-org/project-api --branch main

The command validates migrations, synchronizes the source to GitHub, triggers the platform build, and waits for its result.

Verify


apso status
apso logs
apso open

Open the deployed endpoint shown by the CLI or service dashboard and check /health and /_docs before connecting a frontend.

Repository controls

Flag	Behavior
`--repo owner/name`	Select a repository when no repository is connected.
`--branch name`	Push and deploy the selected branch. The default is `main`.
`--local-git`	Use local Git credentials for the push.
`--skip-push`	Redeploy source that is already synchronized.

By default, the CLI can push through the platform GitHub connection. --local-git is useful in a developer machine or CI environment that already has repository credentials.

Migration controls

apso deploy runs a local migration sandbox before the remote build. When schema changes produce SQL, the CLI shows the statements and requests confirmation.


apso deploy --yes
apso deploy --yes --no-wait

Use --skip-migrate only after diagnosing why the local check cannot represent the target deployment. Skipping the check removes an important review step.

Environment variables

Configure hosted runtime values in the service Environment view:

Add or edit the variable.
Mark credentials as secrets.
Click Apply Changes to synchronize pending changes.
Exercise the dependent service workflow.

Local .env files are not uploaded by Git. Add the same variable names to .env.example without secret values.

API keys and OpenAPI

Create a service key from API Keys, then select it in the service Docs view to exercise authenticated requests. Store the key in a server environment when connecting an application. Do not place it in public frontend variables.

Custom domains

Custom domains are a plan-dependent service setting. Review Settings for the selected service. When the setting directs you to support, use the contact path shown in the application before changing DNS.

Diagnose a failed deployment

Run apso status to identify the failed build.
Run apso logs and find the first generation, dependency, migration, or build error.
Reproduce the framework build locally.
Fix .apsorc, generated dependencies, migration input, or extension code.
Commit the reviewed change and run apso deploy again.

The generated repository remains a standard framework project. You can deploy it outside Apso Cloud with its Dockerfile or framework tooling when your infrastructure requirements call for that path.

Link a repository and understand the push behavior

GitHub connection

Authenticate and deploy from an automated workflow

CI/CD

Run the generated service in your own infrastructure

Self-hosting