Artifacts

An artifact is a file that belongs to a specific deployment — typically a build output such as a tarball, zip, jar, war, binary, or any other packaged result that you want preserved alongside a release. Devpilot stores artifacts at the workspace level and links each one back to the deployment, app, and project it came from, so you can always find the exact package that shipped with a given release.

What Devpilot stores for each artifact

Every artifact record captures enough information to identify, verify, and download the file later:

• Name — The original filename (for example, release-v1.4.2.tar.gz).
• Type — A normalized type inferred from the file extension: tar, tar.gz, zip, jar, war, apk, exe, binary, docker, or other.
• Size — File size in bytes, used to show a human-readable size in the UI.
• Checksum — A SHA-256 checksum computed at upload time so you can verify the file has not been tampered with.
• Description — An optional note you attach when creating the artifact.
• Metadata — A free-form JSON field for any extra attributes you want to record (version tags, build numbers, CI run IDs, and so on).
• Linked deployment, app, and workspace — So artifacts stay scoped to the right release.

How artifacts are produced

Artifacts can be created in two ways:

• As part of a deployment pipeline. Add a hook that packages your build output and uploads it as an artifact for the current deployment. For example, after npm run build you might tar the dist/ directory and register it as an artifact so the exact asset bundle is preserved.
• Manually, from a workspace. Upload a file directly through the Artifacts tab. This is useful for attaching release notes packages, external build outputs, or binaries built outside of Devpilot.

In both cases Devpilot saves the file to workspace-scoped storage, records its SHA-256 checksum, and links the artifact to the chosen deployment, app, and workspace.

Browsing artifacts

Uploading an artifact

Downloading and verifying

Every artifact has a download URL served by Devpilot's file service. Open the artifact in the UI and use the Download action to retrieve it. Use the stored SHA-256 checksum to verify the downloaded file matches what was uploaded — helpful for supply-chain checks and reproducibility audits.

Workspace statistics

The workspace Artifacts page also surfaces high-level stats:

• Total artifacts stored in the workspace.
• Total size across all artifacts.
• Breakdown by type (how many tar.gz, zip, jar, etc.).
• Recent artifacts — the five most recently created.

Use these numbers to keep an eye on storage usage and to notice when a particular artifact type is starting to dominate your workspace.

Retention and cleanup

Artifacts are kept indefinitely by default — Devpilot does not automatically delete them on a schedule. When you no longer need an artifact:

• Delete from the UI. Open the artifact and use the Delete action. This removes the artifact record and its underlying file from storage.
• Soft deletes. Deleted artifacts are soft-deleted in the database before the underlying file is cleaned up, which provides a brief safety window in case of accidental deletion.

Best practices

• Package once, re-use forever. Produce a single artifact per deployment (for example, a tarball of the built assets) and reference it from release notes, rollbacks, or audits.
• Use descriptions. A one-line description ("v1.4.2 production build, includes hotfix for login flow") makes the list scannable months later.
• Attach metadata. Store commit SHAs, Git tags, or CI run IDs in the metadata field so you can trace an artifact back to the exact code it came from.
• Verify checksums. When restoring a release from an older artifact, compare the downloaded file's SHA-256 against the stored checksum before deploying.

Next steps