Sakupa vs. traditional hosting: what actually changes when your AI publishes the site?
I am not the developer of Sakupa. I found this MCP server while looking into how personal AI agents publish websites, and this post covers only what its official site and manual say. This is not a story about my own usage.
The comparison that matters is the workflow, not the server
Traditional hosting usually means a chain of separate steps: register an account, buy a plan, point DNS records, upload files, and then repeat parts of that chain every time you update. Each step lives in a different dashboard, and the person doing it has to keep the credentials for all of them.
Sakupa rearranges that chain. There is no user account and no API key. The MCP server runs locally, generates management credentials on your own machine (stored under ~/.sakupa/credentials/ according to the manual), and the project keeps two local records: .sakupa/project.json for settings and .sakupa/site.json for the site mapping. Instead of logging in somewhere, your environment itself holds the authority to manage the site.
Three differences worth noticing
1. Publishing starts with a read-only check, not an upload.
Before deploy, a tool called analyze inspects the output folder locally and returns the list of what will be published plus warnings about files that should not be published. The agent explains that list in plain language and gets an explicit confirmation before anything goes up. In a traditional flow, the equivalent check is usually something you remember to do yourself.
2. Payment never passes through the chat.
Plan tools (plans, subscribe, billing, change, portal) only return links to Stripe-hosted pages. Card numbers never appear in the conversation, and creating a link does not by itself change a subscription. The agent guides you to the doorway; the payment itself happens on Stripe's page, by you.
3. Recovery replaces "reset your password."
Because there is no account, there is no password reset. If you change machines, a recover tool takes the site back through a device path or a DNS path, and whether old credentials are revoked is always your choice, never the agent's. A separate rotate tool exchanges management credentials after a preview, and old credentials all expire. That is a different mental model from "I forgot my login, email me a link" — and it is worth understanding before you rely on it.
What does not change
Sakupa only handles static sites. If your site needs a database or a login system, this is not the tool for it. The first publish is a free preview (normally 30 days) at https://{shortId}.sakupa.com, and paid plans start at 200 yen per month (Water), with Personal at 500, Share at 1,000, and Business at 2,000 yen. Plans are per site and do not auto-upgrade, according to the official pricing page. And it is a fairly new service (first npm publish in July 2026, per the official timeline), so trying the free preview with a small page first seems the sensible way to evaluate it.
The interesting question is not "is this better than traditional hosting in general" — it depends on what you are publishing. For a static brochure, shop, or company page that changes in small steps, removing accounts, dashboards, and DNS busywork changes the daily experience more than any single feature does. For anything dynamic, the comparison stops before it starts.
Links
- Official site: https://sakupa.com/
- Product page: https://sakupa.com/product/
- Manual: https://sakupa.com/manual/
- npm:
@sakupa/mcp
Top comments (0)