Ways to deploy

Every path below funnels into the same pipeline (ingest → detect → build → probe → publish) and produces the same thing: a live URL. How the code arrives does not change how it is run.

A local directory

jollop deploy .            # the current directory
jollop deploy ./service    # any path

The tree is tarred (skipping junk like .git, node_modules, build caches), uploaded, and resolved. Redeploying an identical tree hits the plan cache and comes straight back up.

A public git repository

jollop deploy https://github.com/you/project

The repo is shallow-cloned on the platform and deployed. Use this for anything already on GitHub or another public git host.

An archive

jollop deploy ./build.zip
jollop deploy ./bundle.tar.gz

.zip, .tar, and .tar.gz are accepted. A .tar is sniffed, not trusted by name: if it is a docker save / OCI layout it is treated as a container image, otherwise as an ordinary source archive.

A container image

jollop deploy --image traefik/whoami

Pulls the image over plain HTTPS (no Docker daemon) for your platform architecture, flattens it, and runs its entrypoint. An image is the one drop that arrives already resolved, so there is nothing to detect and nothing to build.

Naming and identity

Every app has a name (defaulting to the directory or repo name). Redeploying under the same name replaces the previous version in place and keeps the same URL. Pass a different name to run something separately.

From the browser

Open the app and drop a folder or archive onto the drop zone. The deploy stream renders live, exactly as the CLI shows it.