Deployment used to be the hardest part of shipping software. Servers to provision, SSL certificates to configure, load balancers to set up, CI/CD pipelines to maintain. For many teams, deployment day was a stressful, multi-hour event.
At Kaizen, deployment takes under an hour. Often under 15 minutes. Here is exactly how we do it and why the approach works for most projects.
The Cloudflare Pages pipeline
Our standard deployment target is Cloudflare Pages. The workflow is straightforward:
- Push code to the main branch.
- Cloudflare builds the project automatically.
- The build output is deployed to Cloudflare's global CDN.
- The site is live at the production URL.
That is the entire process. No Docker containers, no orchestration tools, no manual steps. Push to main, wait 60 to 90 seconds, done. Every commit is a deployment.
For new projects, the first deployment adds a few extra steps: create the Pages project on Cloudflare, point the domain's DNS, and configure build settings. This takes about 10 minutes. After that initial setup, every subsequent deployment is automatic on push.
Why static exports eliminate complexity
Most of our projects use Next.js with static export. This means the build step generates plain HTML, CSS, and JavaScript files. No server is running. No database connection at runtime. No Node.js process to manage, monitor, or restart.
This eliminates an enormous category of deployment problems:
- No server crashes. There is no server. Static files are served directly by Cloudflare's CDN.
- No cold starts. Files are cached globally and served in milliseconds from the nearest edge location.
- No scaling concerns. A CDN handles millions of requests per day without configuration changes. You do not need to think about load balancing until you have traffic levels that most products never reach.
- No security patches on the server. No server means no server vulnerabilities. The attack surface is the CDN itself, which Cloudflare manages.
For 80% of marketing sites and many product frontends, static export is the right choice. It is faster, cheaper, more reliable, and simpler than any server-based alternative.
Workers for server-side logic
When a project needs server-side logic (API endpoints, webhooks, authentication, data processing), we use Cloudflare Workers. A Worker is a small piece of JavaScript that runs on Cloudflare's edge network, close to users, without a traditional server.
The Kaizen email inbox is a Workers example: incoming emails hit a Worker that stores them in KV (key-value storage) and forwards to Gmail. No server to manage. No uptime to monitor. The Worker runs when called and costs fractions of a cent per invocation.
Workers handle the use cases that static sites cannot:
- API endpoints: CRUD operations, data validation, business logic.
- Webhooks: Receiving callbacks from Stripe, email providers, or other services.
- Authentication: Token validation, session management, OAuth flows.
- Scheduled tasks: Cron-triggered operations like report generation or data cleanup.
The deployment workflow is the same: push code, Worker is deployed globally in under a minute. No Docker, no Kubernetes, no server provisioning.
DNS, SSL, and CDN from one platform
One of the biggest time savings comes from using Cloudflare for everything: DNS, SSL, CDN, hosting, and server-side logic. In traditional setups, these are separate services from separate providers with separate dashboards and separate failure modes.
With Cloudflare:
- DNS: Managed in the same dashboard. Changes propagate in seconds, not hours.
- SSL: Automatic. Free. No certificates to generate, install, or renew. HTTPS works out of the box.
- CDN: Every Page and Worker is automatically distributed to 300+ locations worldwide.
- Analytics: Built-in web analytics without JavaScript tracking scripts.
Setting up a new domain with full HTTPS, CDN, and hosting takes about 5 minutes. Compare that to the traditional approach: register domain (1 day for propagation), provision server (30 minutes to hours), install SSL via Let's Encrypt (15 minutes plus cron for renewal), configure nginx (30 minutes), set up CDN separately (another service, another configuration).
The deploy checklist
Before every production deployment, we run through a short checklist:
1. Build locally. Run the production build on a development machine first. This catches TypeScript errors, missing imports, and build configuration issues before they hit the deployment pipeline.
2. Type check. Run the TypeScript compiler with no emit. This catches type errors that the build step might not surface, especially in files that are not directly imported by a page.
3. Preview locally. Serve the build output and click through the critical paths. Does the navigation work? Do forms submit? Do images load? A 2-minute manual check catches issues that automated tests miss.
4. Deploy. Push to main or run the deploy command. Watch the build log for errors.
5. Verify in production. Open the production URL and repeat the quick manual check. Confirm that the DNS resolves, HTTPS works, and the content is correct.
This entire checklist takes 5 to 10 minutes. It is not a ceremony. It is a habit that prevents the "I deployed and the site is broken" scenario.
Why we skip Docker, Kubernetes, and AWS
Docker is a solution for "it works on my machine but not on the server." When there is no server, that problem does not exist. Static files behave identically everywhere.
Kubernetes is a solution for orchestrating many containers across many servers. When your deployment is "push files to a CDN," there is nothing to orchestrate.
AWS is powerful and flexible, but that flexibility comes with complexity. Configuring an S3 bucket + CloudFront distribution + Route 53 DNS + ACM certificate takes 30 to 60 minutes and requires navigating multiple AWS services. The Cloudflare equivalent takes 5 minutes in one dashboard.
We are not against these tools. They solve real problems at scale. But for an MVP, a marketing site, or a SaaS product with under 10,000 users, they are unnecessary complexity. You can always migrate to AWS or Kubernetes later when your scale demands it. You do not need to start there.
The result
Our deployment workflow lets us go from "code is ready" to "site is live in production" in under an hour for new projects and under 2 minutes for updates to existing projects. This speed is not about cutting corners. It is about choosing tools that make the simple path the correct path.
When deployment is this fast, it changes how you work. You deploy more often, in smaller increments. Each deployment carries less risk because it contains fewer changes. Bugs are caught faster because the gap between writing code and seeing it in production is minutes, not days. The result is software that ships faster and breaks less.