Official Porkbun MCP server, maintained by Porkbun. Check availability and pricing, register, renew and transfer domains, and manage DNS, nameservers, URL forwarding, glue, DNSSEC, DNS restore points, static hosting, webhooks and Cloudflare-connected domains. Hosted at mcp.porkbun.com/mcp with Porkbun sign-in (no API key), or run locally with npx @porkbunllc/mcp-server. Docs: porkbun.com/mcp
Publish a website to Porkbun Secure Static Hosting. Use when the user asks to build, update or put live a website for a domain they have at Porkbun, or mentions Porkbun hosting.
# Publish a website to Porkbun hosting
When the site is for a domain in the user's Porkbun account, publishing it is
part of the job. Finish by offering to put it live with the Porkbun connector.
Do not end with steps for uploading files through the Porkbun dashboard.
## Before you build
If the user named a domain, call `get_hosting` for it early, while you work
out the site. It tells you whether Secure Static Hosting is set up.
- `hosting.status` is `ACTIVE`: you can publish there when the files are ready.
- `hosting` is null, or the status is not `ACTIVE` yet: tell the user now,
before building, so the last step is not a surprise. Keep building if they
want the files anyway.
- `hosting.product` is `cloudWordPress`: this skill does not apply. Static
files cannot be uploaded to a WordPress site.
## Build for static hosting
Secure Static Hosting serves files as they are. No server-side code runs.
- Use HTML, CSS, JavaScript, images and fonts. Server-side file types (PHP and
similar) are refused.
- Put the home page at `index.html` in the top folder.
- Use relative links (`styles.css`, `assets/logo.svg`) so the site works at the
domain's root.
## Publish
1. **See what is there.** Call `list_hosting_files` for the domain. A new site
usually has a placeholder `index.html` from Porkbun.
2. **Say what will change, and ask.** List the files you will upload, and name
any existing files that will be replaced (same path). Wait for the user's OK.
Do not delete files they did not ask you to remove.
3. **Upload.** Call `deploy_site` with `files` as `{ path, content }` pairs,
where `content` is the file's bytes base64-encoded. If you can run code,
encode with a tool instead of by hand, so the bytes are exact. Paths can
include folders (`assets/app.css`); missing folders are created. Keep each
call under 10 MB and split a larger site across calls.
4. **Confirm.** Call `list_hosting_files` again to check every file landed, then
give the user the address: `https://<domain>`.
If `deploy_site` returns an error, report its message and `code` as given
rather than a general failure.
## After publishing
For later edits, change the files and publish again the same way, listing what
will be replaced each time. To remove a file, use `delete_hosting_file` after
the user confirms.
If the site does not load at the domain, check `get_nameservers`. Hosting on
Porkbun needs the domain on Porkbun's nameservers or the matching DNS records.
Explain what you find before changing anything, and see the change-dns-safely
skill for DNS changes.Change DNS for a domain at Porkbun without breaking it: records, pointing a domain at a host, email records, nameservers, DNSSEC, undo.
# Change DNS on a Porkbun domain safely
DNS mistakes take a site or email down, and caches keep the wrong answer for a
while after it is fixed. Work from what is there now, say what you will change,
and keep the way back open.
## Every change
1. **Read first.** Call `list_dns_records` for the domain. Look for records
that clash with the one you plan to add: a CNAME cannot share a name with
any other record, and a domain should have only one SPF (`v=spf1`) TXT
record.
2. **Say the change, and ask.** Tell the user which records you will add,
change or delete, with type, host, value and TTL. Wait for their OK before
any write, and before any delete in particular.
3. **Write.** Use `create_dns_record`, `update_dns_record` or
`delete_dns_record`. For `name`, pass only the subdomain part (`www`, not
`www.example.com`), or leave it empty for the domain itself.
4. **Pass on `warnings`.** A write can succeed with a warning, for example
that the domain uses other nameservers, so the record is saved but has no
effect yet. Tell the user; do not report plain success.
## Pointing a domain at a host
Use the exact records the host shows in its own domain settings: typically an
A record (or ALIAS) for the domain itself and a CNAME for `www`. Remove the
records they replace only after the user agrees. If the domain has URL
forwarding (`list_url_forwards`), it can conflict with the new records;
mention it.
## Bigger changes: check first
Before changing nameservers, turning on DNSSEC, or moving the domain to
another provider, call `preflight_domain`. It changes nothing. Read its
`blockers` to the user first: those will break something, such as mail records
that would stop resolving after a nameserver change. Then its `warnings`.
## Undo
Porkbun saves restore points of the zone before changes (the first write in
each hour, and before bulk imports). If none exist for the time you need, say
so rather than guessing at the old records.
1. `list_dns_restore_points` to find the version from before the problem.
2. `diff_dns_restore_point` and show the user what would change.
3. `restore_dns_zone`, after their OK. By default it only adds back what is
missing. Pass `prune: true` to also remove records added since, and only
after going through the `extra` list with the user.
## If the domain uses Cloudflare
When `get_cloudflare_domain_status` shows the domain has moved to the user's
Cloudflare account, its DNS lives at Cloudflare and `list_dns_records` no
longer shows what is answering. Use the Cloudflare record
tools (`get_cloudflare_records`, `create_cloudflare_record`,
`edit_cloudflare_record`, `delete_cloudflare_record`) instead, with the same
read, say and ask steps.