Skip to content
Platform engineering

Deploy the Artifact, Not the Repository

Deploys a verified local build artifact to Netlify without asking Netlify to rebuild the source project.

Get deploy-prebuilt-app-to-netlify on npm
Website
Written by Montasim
2 min read

The visible feature was only the surface

Deploying an already-built application through a source-oriented hosting flow can trigger unnecessary rebuilds, publish the wrong directory, or upload unsafe local artifacts.

The system also had to respect concrete constraints. The requested artifact must be validated before any remote mutation. Secrets, source trees, caches, and unrelated files must never enter the deploy payload. Site selection, production promotion, and deployment are separate authorization boundaries.

My role covered agent workflow design and automation engineering, with responsibility for deployment, deterministic validation, and portable distribution.

I turned the constraints into boundaries

Local artifact and publish-directory preflight; Netlify CLI flow selection with explicit mutation gates; deployed URL and content verification.

Keep prebuilt delivery separate from source builds and their dependency graph.

Run local safety checks before requesting credentials or mutating remote state.

Treat a successful CLI exit as incomplete until deployment state and served content are checked.

The key decision: Deploy the artifact, not the repository.

The implementation had to prove the model

I delivered the work across the full path: Defined safe artifact-tree acceptance rules. Implemented a deterministic preflight utility. Separated draft, production, and site-selection authorization. Added package and deployment-flow regression tests.

The result is concrete: Agents can deploy a verified local build without asking Netlify to rebuild source. Unsafe payloads fail before remote changes. Authorization remains scoped to the requested deployment stage. The final report distinguishes local validation, mutation, and public verification.

The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.

Working through a similar challenge?

Share your context, constraints, and timeline to start a focused conversation.

Leave a reply

Respond to the article or continue the discussion.

Ctrl + Enter to post

Your email stays private. Comments are stored securely.