I just want to push index.html and not think about it

You have a finished page. One index.html, a stylesheet, a couple of images sitting beside it. You want it at an address you can send to someone. That is the entire request.

It is a reasonable request. It is also not the request the tooling around you is built to answer. Ask where to put a finished file and the answer arrives as a workflow: a repository, a build command, an output directory, an environment, a pipeline. Each step is defensible. Together they answer a question you did not ask.

This is not a complaint about any one host. It is a note about who the whole category was designed for, and what happens to everyone else.

What people actually ask

In late 2023 someone posted a short question to Hacker News titled Ask HN: Why is Deployment so Hard? The opening line:

There are so many tools available to help make deploying code easier but it's still one of the most feared/hated parts of software development for most people I know.

The thread collected two points and exactly one reply — "Maybe just do heroku then" — and sank. Worth being precise about what that post is: the author is asking about deploying code, and mentions Kubernetes and Terraform. It is a developer's question, not ours. The interesting part is that even in its own home territory, asked of an audience that deploys for a living, the question drew a shrug.

The version of the question that matters here shows up somewhere else. In a May 2026 thread about agents buying domains and deploying on their own, a commenter described what they were watching happen around them:

I am watching people who can't code build and deploy dashboards and sites with Claude Code (desktop app - they don't use the CLI), then go cap in hand to developer friends to get it hosted on a domain (rather than some Vercel or whatever URL).

Cap in hand. The site exists. It works. The last step requires knowing somebody. Three weeks earlier, someone building small tools for their own use described the same wall from the inside:

I myself have been vibe coding so many tiny apps/scripts/cron jobs that resolve tiny inconveniences in my life and the biggest pain point for me right now is making these available to my multiple devices over the internet.

The building is not their bottleneck. They are shipping cron jobs and scripts without help. Getting the finished thing to a URL is.

And this is not only about people who are new to it. In September 2025, someone who runs several static sites, reacting to a hosting pricing change, put it plainly:

I find it surprisingly difficult to find a host for simple static sites.

That complaint is about billing rather than pipelines, because the thread was a new per-request pricing page, not a setup guide. But the sentence that follows has the same shape as everyone else's:

But all the hosts are like, "No, we include geo-redundancy! We include AI cloud functions! Move your build system to us, and then we'll bill you for every minute of your build!"

Four people, from late 2023 to mid-2026, at different levels of skill, one shape of request: I have a finished thing, I want it reachable, please do not make this a project.

What they get told instead

Search the question and the results are competent and beside the point. Step-by-step guides open with source control and a build stage. Best-practice articles cover staging environments, environment variables, rollback strategy, zero-downtime releases, CI runners. Discussion threads turn into stack comparisons within a dozen replies.

None of it is wrong. All of it assumes the thing being deployed is an application under active development by a team — something with state to protect, secrets to inject, and a release process worth defending.

An index.html with a stylesheet next to it has none of those properties. It has no state, no secrets, and no release process to protect. Yet it inherits the whole apparatus, because the apparatus is what "deployment" means now.

Deployment is priced for applications

Here is the claim I will defend: the cost of deploying was set correctly for applications, and has never been re-examined for documents.

That price was earned. Deploying a real application genuinely was dangerous, and the industry spent years building discipline to make it survivable — reproducible builds, versioned artifacts, staged rollouts, automated rollback. That work paid off. Nobody sensible wants to give it back.

What did not happen is anyone checking whether the same price applied to a page. The default hardened around the harder case, the simpler case was quietly filed underneath it, and the ratio stopped being noticed. A folder of browser files now travels the same road as a system with a database, because it is the only road that got built.

You can see the inheritance in the language. A finished page does not need to be built, but you will configure a build command. It has no environments, but you will pick one. It cannot break production in any meaningful sense, but you will be offered a preview deployment to protect against that.

The tell is that nobody argues for this. It is not a position anyone holds. It is a default nobody revisited.

Where the complexity is real

The honest exception matters, because the argument above collapses if applied too widely.

If the project owns a database, user accounts, private API keys, server-side code, or scheduled work, the machinery is not overhead. It is the reason the thing keeps working. Environments, secrets management, and a rollback plan are what stand between a routine change and a bad weekend. A site that stores other people's data deserves every stage in that pipeline.

The mistake is not that this discipline exists. The mistake is that it became the entry point, and the simpler case never got its own door.

It is also fair to say the gap is not a secret, and that other people are filling it. The commenter with the cron jobs, quoted earlier, is building their own answer — a shared host for small self-built programs, aimed at exactly this problem. They are not the only one. When several people independently start building the same missing thing, the thing is missing.

The short version

If what you want is the mechanics — what counts as "the page", why the file is called index.html, what travels with it — that is a separate question with a direct answer, and it is written up in how to host an HTML file. And if you are meeting the same wall one layer up, inside a Claude artifact, that case has a page of its own.

The point here is narrower. A finished page should reach an address without becoming a project, and where that already works, it works because the publishing step was matched to the object being published, not inherited from a harder one. That is the loop Birta is built around: the agent that already has your finished files publishes them to a live HTTPS address, every published version is kept so a bad change can be rolled back, updating it later without redeploying the whole thing runs through the same connection, and your own domain points at it when you want your name in the bar. Static sites only — if your project owns a database or server-side code, use something built for that and give it the review it deserves.

For the wider argument about what that publishing layer should look like, see vibe deployment. For the walls that appear after the address, the domain, the form and the payments, see the deployment gap.

Push index.html, get an address, go back to what you were doing. It should not be a category-defining request.

And if you have no file to push yet, that is not a different problem so much as an earlier one. Building a site without a builder starts at the empty page and ends at your own domain.