Builds and deployments

Choose a source

A service can build a GitHub repository, run a container image, or receive a local source archive through the CLI. Automatic builders support Node.js, Python, and Go projects; use a Dockerfile when you need explicit system packages or build steps. Pin important runtime and dependency versions in the repository.

For a monorepo, set the root directory correctly. Build watch patterns can limit which repository changes trigger an automatic deployment. A configured GitHub branch is used for automatic pushes; an environment can override the branch.

Repository builds reject special files and symbolic links that are broken or resolve outside the repository. Links within the repository are supported. CLI source archives cannot contain symbolic links, hard links, or special files. An archive is limited to 500 MiB compressed and 1 GiB uncompressed, including archive metadata, with at most 100,000 entries and 64 components in a path. If a build fails these checks, remove or replace the affected files, or reduce the upload, then deploy again. These checks apply to new source builds after the platform update; they have no service-level disable switch and do not change running deployments.

Build, prepare, and start

Build and start commands can be set in the panel or upferry.json. A pre-deploy command runs before publishing the new application. A failed command prevents that deployment from becoming active. Pre-deploy database changes are not automatically reversed if the application later fails.

Configure the listening port and an HTTP health check. The check should become healthy only after essential dependencies are ready. A deployment page records its source revision, effective configuration, build output, and result.

Scheduled jobs

A cron service runs its command on a five-field cron schedule in UTC. It is not a continuously running HTTP server. Review run history and exit status; the CLI can list or trigger runs. Existing jobs keep the configuration with which they started.

Updates and rollback

A GitHub push can trigger a new deployment. The panel also supports manual deployments, cancellation, and rollback from deployment history. Check the selected environment before acting. Rollback restores application code through a deployment; it does not undo schema changes, external requests, or database writes.