Deploy from a ZIP
Upload application source, review detected build settings, and reuse an immutable source archive for manual deployments.
Upload application source as a ZIP when the project is on your computer or arrives as a downloadable package. Openstead validates the archive and builds it through the same isolated build pipeline used for repository source. Uploading a ZIP does not deploy the application or purchase paid compute.
Prepare the source
Include application code, manifests and dependency lockfiles. Leave out installed dependencies such as node_modules, vendor and virtual environments; the build installs them from your manifests.
| Limit | Maximum |
|---|---|
| Compressed ZIP | 64 MiB |
| Total expanded files | 256 MiB |
| One expanded file | 64 MiB |
| Archive entries | 10,000 |
Openstead rejects unsafe paths, duplicate file paths, symbolic links, special files, encrypted entries and archives with excessive expansion. A single enclosing folder is removed so the application can be detected at the archive root.
Local .env files, Git metadata and installed dependencies are removed. Environment examples such as .env.example, .env.sample and .env.template remain, as do application license files. Move real database credentials, application keys, purchase settings and license settings into Environment Variables before deploying. Preserve an existing application's encryption key when migrating encrypted data.
Create a service
- In the dashboard, choose New and the application service type.
- Select the ZIP source option and upload your archive.
- Review the detected framework, runtime and build method, along with the removed-file report.
- Choose Use this source, then review the build command, start command, port, project and environment.
- Save the service. If it uses a paid instance, review and complete its service-month checkout.
- Start a deployment and follow its logs until the release becomes live.
A newly uploaded archive must be selected and accepted within one hour. If the staged selection expires, upload again. Accepted source remains reusable within its workspace. Upload and source changes require developer or greater access; reusing source belonging to a protected service or its retained releases requires admin access.
Build detection is a starting point. A Laravel project still needs its application key and database connection; a server-rendered Next.js project still needs a web service. Review the matching framework guide before releasing.
Replace an existing service's source
Open Settings → Source. Select a new ZIP or an accepted saved archive and save the source configuration. Then deploy to build and activate it. Saving a source does not replace the running release.
ZIP deployments are manual. Repository branches, commit-triggered auto-deploy and pull-request previews apply to Git source. To change code in a ZIP service, upload a new archive and choose it for the next deployment.
Each deployment records the exact archive identity, checksum and build configuration. A later source upload does not rewrite an old release. Rollback still requires a retained successful artifact and does not roll back database contents or user uploads.
Reuse and remove source
Saved archives can be used by more than one authorized service in the same workspace. Source needed by a service, Blueprint or retained deployment cannot be deleted while those references remain. Discard unused staged uploads and remove unused accepted archives through the source controls.
Expired staging and unused source cleanup run asynchronously. Keep your own source backup: an uploaded archive is a deployment input, not a version-control history or a database backup.
Troubleshoot
Upload is unavailable: the console reports when its private upload connection is unavailable. Reuse an accepted source if offered, or try again after service recovery. Repeated uploads do not resolve an unavailable connection.
The archive is rejected: remove dependency directories, check the compressed and expanded sizes, and recreate a regular ZIP containing application files without links or encrypted entries.
Build detection chose the wrong stack: review the archive root and manifests, then set the supported build method and commands explicitly. See Build configuration.
The release lacks a setting: inspect the removed-file report and move the required value from the local environment file to a secret variable. Save it and deploy a new snapshot.
To create a configured application without preparing an archive, use a starter template.