Cloudish

Cloudish guides deployment of a Dockerfile, source folder, or existing container image to a live HTTPS URL. Builds happen on Cloudish servers, so the workflow does not require a local Docker daemon. It covers project preparation, API-key handling, confirmation before deployment, build monitoring, application verification, and diagnosis from real logs. The skill is MIT-licensed.

Inspect the entry point, declared HTTP port, existing Dockerfile, environment requirements, and data that must survive restarts. Reuse a suitable Dockerfile or prepare a minimal one for the stack. The server must bind to 0.0.0.0 on the declared port so the proxy can reach it. Source deployments upload a tar.gz context with a Dockerfile at its root; existing images use an image reference instead.

Build an inspected, allowlisted staging directory outside the application directory. Exclude credentials, private data, symlinks, .env files, and Git metadata rather than assuming tar respects .dockerignore. The example packaging step is:

tar -czf ../context.tar.gz -C ../approved-build-context .

Reuse a key only after checking its intended project ownership without exposing it. Creating a new key requires explicit authorization; capture the response privately and save the credential in an ignored configuration file. Use a protected API client or configuration rather than expanded secret arguments. A returned claim URL is a sensitive capability for the authorized owner, not a public report artifact or application login.

Before the first deployment, describe the project, uploaded content, public reachability, and credit use, then wait for confirmation. Additional spending beyond the request, including larger instances, extra replicas, always-on operation, or transfers, also needs confirmation. Verify current service terms rather than treating prepaid-credit or encryption statements as guarantees.

The projects API creates or updates a deployment, including redeployments. Optional settings include non-secret env values, replicas, and volume configuration. Follow build status with bounded polling and report only new, redacted log lines. On failure, inspect the build error and log tail; a generic backoff message alone is not a diagnosis. Reconcile ambiguous writes before retrying.

Report the returned subdomain.url only after checking that the application responds. If it fails, inspect container logs and Kubernetes events such as ImagePullBackOff or FailedMount before changing resources. A completed build alone does not establish a working service.

SQLite or Postgres can run inside the container with a persistent volume; there is no managed database service. A volume forces a single replica, and only one HTTP port is exposed per container. Secrets belong in the secrets endpoint rather than image layers or ordinary env configuration.

Network access and credited API access are required; exhausted credits produce HTTP 402. Instance choices, volumes, and timeouts follow API-defined sets that can change. The skill does not configure custom domains, CI, or authentication inside the application. Default public reachability requires particular care with sensitive apps: provision authentication before upload, and remove or rotate a subdomain when appropriate. URL rotation is not a substitute for authentication.