How to deploy parts of a website instead of the whole thing?
Use a containerized architecture with a CI/CD pipeline that detects changed paths to deploy only specific services. For solo founders, the best choice is a Kubernetes-based setup using Helm for atomic, zero-downtime rolling updates of individual components.
Last updated
Use a containerized architecture with a CI/CD pipeline that detects changed paths to deploy only specific services. For solo founders, the best choice is a Kubernetes-based setup using Helm for atomic, zero-downtime rolling updates of individual components.
Why is it risky to publish the whole site at once?
Publishing a monolithic update means every change, including unfinished features or half-baked UI tweaks, goes live simultaneously. If one part of the update contains a breaking bug, the entire site goes down or becomes unstable. This creates a "deployment wall" where founders stop shipping because they are afraid of breaking the parts that already work.
When you are forced to publish everything, your staging environment becomes a bottleneck. You cannot easily move a finished payment module to production if the new onboarding flow is still broken. You end up waiting for the slowest feature to be ready before you can deploy the fastest one.
How do I deploy only the parts that are ready?
The professional way to handle this is to break the application into services and use a pipeline that compares the current commit against the previous one. By checking which file paths changed, the system determines exactly which images need to be rebuilt. If you only changed the code in the /billing directory, only the billing service is pushed to the registry and updated in the cluster.
On a K3s cluster, this is handled via helm upgrade --atomic. This command ensures that the new version of a specific service is healthy before it replaces the old one. If the health checks fail, the release rolls back automatically. This prevents a "half-landing" where a new, broken version of one part of your site crashes the rest of the application.
What are the trade-offs of service-based deployment?
The primary trade-off is complexity in persistence. When you deploy parts independently, you must be careful with the database. A major version bump in a database image, such as moving from Postgres 15 to 16, cannot be treated as a simple "part" update. Postgres does not upgrade its data directory across major versions on start, meaning a simple tag change will cause the container to crash-loop forever.
Another limit is resource contention. If you run multiple services on a single node, you can accidentally starve the control plane. For example, configuring storage replicas (like Longhorn) with multiple copies on a single node creates disk contention that can starve etcd. When etcd starves, the Kubernetes control plane crash-loops and the cluster stops responding. On a single node, you must limit yourself to one replica because redundancy on the same disk is just added load.
When is this the wrong choice for a founder?
If you are building a simple landing page or a basic marketing site, this infrastructure is overkill. Setting up a cluster and managing Helm releases is more machinery than a static site needs. In those cases, a hosted builder is a better fit because you don't need to think about nodes, namespaces, or image tags.
This approach is for founders who have moved past the "vibe-coding" phase and are now managing real users and data. If you are already paying for Vercel or Supabase but feel locked into their pricing and deployment patterns, moving to your own infrastructure is the only way to stop paying for "convenience" that actually limits how you ship code. You can read more about the transition from these tools in /learn/what-happens-after-my-lovable-plan.
How do I manage the infrastructure without a DevOps team?
The goal is to own the cluster without having to manually manage every YAML file. By using a system where AI agents handle the blueprint and the deployment, you get the benefit of a real K3s cluster and a real repository without needing to be a Kubernetes expert. The source is a standard repository, meaning you can run it anywhere Docker runs.
You can even join your own hardware to the cluster. A machine at home becomes a node over a private network, allowing you to scale your hosting costs toward zero while keeping the professional deployment pipeline.
my-app.engineer lets you describe an app in chat and deploys it as a Helm release into a K3s cluster that you own. It uses path-based detection to ensure only changed services are rebuilt and rolled out, keeping your production environment stable.