# Storage and Release Artifacts > Understand the difference between immutable deployment artifacts and application data. Source: https://nexthomelabs.com/docs/storage Markdown: https://nexthomelabs.com/docs-md/storage Slug: storage Section: Create Last updated: 2026-08-30 Reading time: 5 min read --- # Storage and Release Artifacts Each successful build produces the **artifact** used for that release — a deployment output, not the project source. Release artifacts are **managed by NexHost** and are separate from the source archive or repository you uploaded. That separation is deliberate: source keeps intent ("what the team wrote"), artifact keeps what actually ran ("what the platform built and served or started"). Understanding which layer is mutable and which is immutable prevents two common errors: editing a previous artifact as if it were a file store, and treating a deployment release as a database. ## The two layers | Layer | What lives there | Mutable? | When it changes | | --- | --- | --- | --- | | **Source** | Repositories, ZIP archives, local folders, or container image references you select on creation | You control it — push, re-upload, or re-reference. | When you change code and select it as the deployment’s source. | | **Artifact** | The built output: the published static directory for a Static Site, or the captured build + launch configuration for a runtime service | **Immutable** — a successful release’s artifact is not retroactively patched | When a deployment runs and the build/start steps produce a new recorded artifact. | | **Application data** | The durable, long-lived state your users create — rows in Postgres, files intentionally stored behind an application API, uploaded media where you decided how to persist it | Managed by you — via the data services the application talks to | Continuously, under the traffic your service serves. | > [!INFO] > There is a third layer only for private context: **deployment build output** (the logs) is also a retained, immutable record per deployment. It is useful for diagnosis but is not application data. ## Release artifacts Static Sites publish the **configured output directory** (for example `dist`, `out`, or `build`). Runtime services (Frontend Apps, Web Services, Private Services, Background Workers, Cron Jobs) use the **prepared build and startup configuration** for their release — install command, build command, start command, root directory, and environment variable snapshot as recorded at deployment time. Treat artifacts as **deployment outputs**: - Make source changes in your **repository or archive**, then create a **new release** rather than editing a previous artifact. Patching an artifact would invalidate the history that lets you compare two deployments and rewind when needed. - Do not rely on the local filesystem of a deployment as durable storage. A future deployment can re-provision, a scale event can re-place the workload, and an artifact is replaced — not merged — by the next successful release. - Review the deployment detail page after each release to confirm the artifact you expected was produced: the published directory listing for a static site, or the captured build/start capture for a runtime. ### What happens between two releases A new deployment re-runs the build (when the service requires one) and re-records a new artifact. Previous artifacts remain in history so you can compare or restore. Overwriting the source in Git is not overwriting the artifact — the platform keeps both layers’ provenance distinct. ## Application data Do not rely on a deployment artifact as **mutable application storage**. An upload directory placed inside a runtime image or inside a static output folder is not durable: the next deployment can replace it, and uploading directly onto an artifact without an application-owned path is a pattern the platform cannot guard for you. Store durable relational data in [Postgres](/docs/services/postgres) or use the data service appropriate to the application — a database the platform manages, or an external store you integrate with. Keep backups and data-retention decisions **under your team’s control**, not as an accident of which file happened to persist between two releases. Good planning habits before shipping: - Decide whether the feature needs **row data** (relational — favorite Postgres candidate), **blob storage** (large objects where the dashboard does not offer a blessed store), or **no persistence** (ephemeral preview data). - Wire the **connection string or provider credentials** to the application service as scoped environment variables, not as checked-in configuration. - Record your **backup and retention expectations** alongside the service configuration — so on-call knows whether "rollback to yesterday’s artifact" should also restore a database. ## Secrets and uploads Keep secrets in [Environment Variables](/docs/configuration/environment-variables), not in source or release files. A `.env` committed to a repository is permanently in history even after you rotate the value; a dashboard-scoped environment variable is not. The same principle applies to user input: treat user-provided content as **data**, not as code to commit. For user uploads and generated media, decide **how they will be stored before deployment**. Depending on your needs, that path may be a database row, a provider bucket behind an integration call, or opaque storage in an external system. A deployment release can change independently of that application data — uploads that happen after the previous release are not "lost because of the next deploy" unless the application rolled its own naive filesystem store into the artifact. Decide that path explicitly, because moving it after users rely on it is disruptive. > [!WARNING] > Avoid committing or layering secrets into images and artifacts. The layer history preserves them. Rotate a credential the moment you suspect it was ever captured into an artifact or log — do not wait to "check later." ## Related documentation - [Postgres](/docs/services/postgres) — the managed database to pair with runtime services when durable relational data is needed. - [Environment Variables](/docs/configuration/environment-variables) — keep credentials out of source and scope them to Build/Runtime/Both. - [Deployments](/docs/deployments) — how releases and their artifacts evolve and how restoration works. - [Logs](/docs/operations/logs) — reading artifact-linked output without leaking secrets.