Deploying Apps

There are three ways to deploy to Caster: paste code, upload a file, or git push. This page explains how deployments work, how to view build logs, and how to roll back.

How Deployments Work

Every deployment follows the same pipeline:

  1. Receive — Caster receives your files (paste, upload, or git push)
  2. Build — A Docker image is built from your custom Dockerfile, or your files go straight to the shared static web server (see below)
  3. Deploy — The new container replaces the previous one
  4. Route — HTTPS traffic is routed to your container automatically

The entire process typically takes under a minute.

Deployment Methods

Paste Deploy

Paste HTML or other files directly in the browser or via the API. Best for quick deploys and chatbot-generated sites.

File Upload

Upload a .zip, .tar.gz, or .tar archive. Good for projects with multiple files.

Git Push

Push to main to trigger a deployment. Best for ongoing development. No prior account or SSH key registration is needed — Caster auto-provisions both on first push using your git commit email.

Static Sites

If your project doesn't include a Dockerfile, Caster serves it as a static site from a shared, always-on Apache web server — no container is built, so deploys are nearly instant and static sites never scale to zero.

PHP is supported out of the box. Any .php file is executed by Apache (PHP 8.3), and index.php works as a directory index (index.html takes precedence when both exist). This is meant for lightweight dynamic pages — contact forms, small CMS-ish sites, templating. The static runtime is deliberately restricted:

  • Read-only files — your site files can't be modified at runtime; only a small per-request /tmp scratch area is writable, and it doesn't persist.
  • No shelling out or network calls — exec, shell_exec, system, curl, sockets, and URL wrappers (file_get_contents('https://...')) are disabled; PHP pages cannot call external APIs.
  • No .htaccess — Apache overrides are ignored.
  • Limited PHP configuration — no custom php.ini, extensions, or Composer. PHP sessions use a container-local store shared across sites, don't survive server restarts, and must not hold secrets; prefer signed/encrypted cookie sessions.

If you need any of those — PHP extensions, writable storage, your own php.ini, background workers — add a Dockerfile instead (see PHP via Dockerfile) and your site runs as a dedicated container.

If you include a Dockerfile, Caster uses it instead of the static runtime — this lets you deploy dynamic apps in any language.

Viewing Deployment History

From the site detail page, you can see all deployments with their status, commit/content hash, and timestamp. Click Logs on any deployment to view the build output.

Build Logs

Build logs show the full output from the Docker build. If a deployment fails, the build log will contain the error. Common issues:

  • Build errors in your Dockerfile
  • The container not listening on the port declared by EXPOSE (defaults to 80)
  • Missing dependencies