Deploy apps from GitHub or your workspace

For a dashboard deployment, connect GitHub and select the repository, branch, and app root. For a local deployment, use an authorized MCP agent with Git and local command access. The workspace route uploads a reviewed commit to private Resilis-hosted source and verifies the chosen revision before deploying it. It does not require GitHub.

Automatic builds use Railpack. Review its detected settings rather than assuming every framework needs no configuration. Select Dockerfile when your repository defines the image build and runtime commands. The recorded examples show both routes for the Node.js task board. They demonstrate those samples, rather than compatibility with every language or framework.

Check the start command, port, dependency files, and environment variables against your app. Keep credentials out of source and mark sensitive variables appropriately. Workspace deployment does not support named build contexts. Use the existing guides for the exact sample settings and check your own app after adapting them.

• Railpack Node.js example →
• Dockerfile example →
• GitHub deployment steps →

Choose the project and environment deliberately. An environment distinguishes the configuration and deployment you are changing. Check that database placement and network access match the app target. A private connection that works in one environment may not resolve in another; the PostgreSQL guide keeps both resources in the same project, environment, and region.

Application processes and persistent data have separate lifecycles. An in-memory app loses changes when its process is replaced. Bind a managed database if the app needs persistent records, or configure an appropriate storage service. Rebuilding an image does not turn memory or container-local state into a database.

• Database and storage configuration →
• Verify PostgreSQL persistence →

Connect an existing Linux VPS or Kubernetes cluster through the Resilis connector, then select the ready target for a deployment. You need authority to install the connector on that infrastructure. Review the setup provided for the selected target and keep enrollment credentials private. Target health and advertised capabilities determine which operations Resilis can request.

On a Linux VPS, the Docker/VPS agent creates or verifies a Resilis-owned Docker network and runs managed containers within that boundary. Existing containers and host services are not automatically adopted. A conflicting resource or occupied port can prevent deployment; connecting compute is not permission to stop another workload.

For Kubernetes, the connector uses in-cluster credentials. The managed-space boundary uses Resilis-owned namespaces and labeled resources. Connecting the cluster does not install an ingress controller, replace its networking, or migrate existing workloads. Plan those dependencies with the cluster owner before choosing how the app will be reached.

Provisioning connected compute and migrating an existing application are separate tasks. Review dependencies, configuration, secrets, storage, and traffic before a migration. Any source retirement requires separate approval. Connecting compute does not make the Resilis control plane self-hosted or establish feature parity with Resilis-managed compute.

Custom domains are not available on connected compute. Confirm this restriction before choosing a VPS or cluster for an app that needs its own domain. Your infrastructure provider remains separate; do not treat Resilis plan credit as payment for the VPS or cluster bill.

Check deployment status and bounded build logs first. For supported containers, use runtime logs and CPU, memory, and network metrics to investigate failures after startup. Open the serving URL and perform a real action. Keep the source revision and environment in view so that you do not inspect a different release by mistake.

Available controls depend on the resource and target. S3-backed static sites do not expose container runtime logs or custom-domain configuration. Autoscaling is not part of the current app-creation path. Do not infer those features from the presence of a deployment status or a plan domain allowance.

Review the next source revision and configuration before releasing an update. Where supported, an authorized user or agent can restart, redeploy, or roll back an application. Check the resulting application behavior again after any recovery action; selecting an earlier release is not proof that its dependencies remain compatible.

App rollback does not restore data or reverse database migrations. Plan database recovery separately and verify compatible application and schema versions before a rollback. Review the resource rates and plan credit when adding replicas, capacity, disks, or databases. The published example estimates a specific app and database workload, not every deployment.

• Database protection and restore limits →
• Usage rates →
• Compare plans →