Why Deploying Static Sites Got So Complicated (And How to Fix It)

Let's be real: publishing a static website shouldn't require a computer science degree.

Yet here we are in 2024, watching developers waste hours setting up CI/CD pipelines, debugging deployment scripts, and fighting with platforms that claim to "just work" but somehow end up making everything harder. It's frustrating, to say the least.

Then you stumble onto something like pgs.sh—and suddenly remember that deployment can actually be simple.

The rsync Comeback

What makes pgs.sh so refreshing is its approach: don't reinvent the wheel.

Instead of forcing you to learn another CLI or figure out some proprietary upload system, it uses something you probably already know. That tool is rsync.

If you've been building for the web for any length of time, rsync has likely saved your skin more than once. It's the reliable workhorse of file transfer—quick, solid, and proven over decades. pgs.sh essentially gives rsync a cozy home on the web, with automatic TLS encryption bundled in.

The entire setup looks like this:

rsync -rv public/ pgs.sh:/myproj/

That's the whole thing. Your public/ folder, synchronized straight to a live URL. No YAML configurations. No webhook debugging. No waiting for build environments to spin up.

Why This Matters

Here's the thing about complexity: it piles up fast. What starts as a "temporary" simple deployment process has a way of becoming technical debt that follows you around for months. Every config file is another potential failure point, another thing your new teammate has to learn, another layer between you and actually shipping.

When you remove the unnecessary stuff, you get:

Speed. Not just the actual deployment time, but the mental load. You're not jumping between dashboards and documentation. You just run a command you already understand.

Reliability. Fewer components means fewer things that can break. Your workflow doesn't depend on a CI provider staying online. There are no surprise rate limits to deal with. Just rsync doing what it's done since 1996.

Flexibility. rsync knowledge travels with you. That deploy script you write today will work whether you're on pgs.sh, your own server, or someone else's infrastructure. That's valuable.

The Philosophy of Purposeful Limits

There's a bigger lesson hiding here about the tools we pick and build.

We've somehow convinced ourselves that more features equal more value. That a deployment service needs Kubernetes support, preview environments, branch deployments, analytics dashboards, and AI optimization to be worth using.

But pgs.sh flips the question: what if the best feature is actually no feature?

This isn't about rejecting progress—it's about intentional focus. By narrowing what the tool does, pgs.sh nails that one thing perfectly. No feature comparison to decode. No pricing tiers to figure out. No sales team sliding into your DMs.

For startups moving quickly and developers who just want to ship, that kind of clarity is genuinely worth something.

When Simple Makes Sense

Let's not pretend one-command rsync deploys solve everything. Applications with backend APIs, databases, and dynamic routing need more robust infrastructure. Cloud platforms, container orchestration, and full CI/CD pipelines exist for good reasons.

But for the countless static sites, landing pages, documentation, and side projects that form the backbone of the web? The simple approach wins every time.

Even for bigger projects, there's real value in keeping your static assets deployment dead simple while saving complexity for where it actually matters.

Wrapping Up

The best tools usually feel obvious in hindsight. Of course deployment should be this easy. Of course you shouldn't need a DevOps certification to publish a webpage.

pgs.sh is a gentle reminder that the tools we use daily deserve the same care as the products we build. Sometimes the most impressive engineering decision is knowing what not to include.

If you've been sticking with complicated deployment setups out of habit, it might be worth exploring simpler alternatives. Your future self—and your users—will appreciate it.

What's your take on deployment? Team complex pipelines or keeping things minimal? I'd love to hear how you approach shipping your projects.