Deploy manually

Most storefronts should deploy from Git, so that a push builds and ships. But sometimes you want a one-shot deploy: a first proof of concept, a build produced by a pipeline that lives elsewhere, or a repository you can't connect yet. For those, upload the build output directly.

Build and package

Build your storefront locally, then package the build output — not your source tree — as a .tar.gz. For a SvelteKit app whose output lands in ./build:

npm run build
cd build
tar --exclude code.tar.gz -czf ../code.tar.gz .

The archive's contents must sit at its root. Packaging the directory rather than its contents produces an archive with one top-level folder, which is the most common reason a manual deploy builds but serves nothing.

.tar.gz is the only accepted format — a .zip will be rejected.

Upload with the CLI

The quickest path, and the one that scripts:

revenexx sites create-deployment --site-id <SITE_ID> --activate true --code .

For a theme or any build directory where you'd rather not manage the site by hand, the one-command form finds or creates the site for you:

revenexx deploy site .

Both are covered in Deploy from CLI.

Upload in Cockpit

In Cockpit, manual upload is one of the two ways to create a site: under Experience Studio → Sites, start a new site and choose the manual upload path rather than the Git path. You supply:

• the .tar.gz of your build output,
• a name and site ID,
• the framework, install command, build command, and output directory,
• any environment variables the build or runtime needs.

Then deploy. A site created this way has no repository attached, so subsequent releases are further uploads rather than pushes.

What you give up

Worth being deliberate about, because the trade is easy to forget once it's working:

• No automatic redeploys. Every release is a manual step, which means it's a step that gets skipped under pressure.
• No commit or branch preview hostnames. Those are derived from Git metadata; a manual deployment gets its unique preview host but not the commit- and branch-keyed ones. See Previews.
• No link back to a commit. When something breaks in production, "which code is this?" has no automatic answer.

Rollback still works normally — any ready deployment can be activated, however it was created. See Instant rollbacks.

Debugging

• The build succeeds but the site serves nothing. Check the archive layout: tar -tzf code.tar.gz | head should show your files at the root, not nested under a folder.
• A configuration change had no effect. Build settings apply to the next deployment. Upload again.
• The upload is rejected. Confirm it's .tar.gz, not .zip or a bare .tar.