Local Directory

Deploy code straight from your machine with the CLI, without pushing it to Git first. Zenavo builds the upload exactly like a repository: with its Dockerfile, or with zbpack when there is none.

cd my-app
zenavo deploy web --dir .

The CLI packs the directory, uploads it as the service's source and follows the build. Run the same command again to deploy a new version.

Which service

• zenavo deploy <service> --dir . uploads to that service. If the project has no service by that name, it is created.
• Without a service name, the project's only service is used. In a project without services, a service named after the directory is created; with several, the CLI asks (or pass --service).

A new service gets an HTTP port from --port, from the port the build plan detects (EXPOSE in a Dockerfile), or 8080, the port zbpack images listen on. Give it a domain afterwards with zenavo domain add.

An existing service keeps its root directory, Dockerfile path, build arguments and zbpack options. Its Git or image source is replaced by the upload, and auto deploy is turned off. Switch it back to a repository in the service's Settings.

What is uploaded

Never: .git, .hg, .svn and .DS_Store.

With a .zenavoignore in the directory (.gitignore syntax), only it decides what else is left out. Without one, the CLI leaves out node_modules, Python virtualenvs, __pycache__, and .env files (except .env.example), plus everything the directory's .gitignore and .dockerignore list. Dependencies are installed again during the build; set secrets as variables.

Uploads are limited to 500 MB compressed and 2 GB unpacked. Symbolic links must stay inside the directory: the CLI leaves out any that point elsewhere and warns about them.

Where uploads are kept

Uploads are stored on the control plane, readable only by builds of your team. A service's earlier uploads are deleted once a newer one is an hour old, and all of them with the project. Rollbacks don't need them: every deployment's image is kept in the registry.