Products
Four capabilities, one account, one bill. Everything below is reachable from the console and from the API, because the console is a client of the API.
Sites and deployments
A site is a name for a series of deployments. A deployment is an immutable set of files with an identifier.
Uploading does not publish. You upload the files, then activate the deployment, and activation swaps the whole set at once. A request that arrives during the swap sees either the complete old deployment or the complete new one. It never sees a mixture, and it never sees an upload that has not finished.
Rollback is the same operation, pointed backwards. Any deployment still retained can be made active again, atomically, with no re-upload. The number of retained deployments is bounded, and a deployment past the bound stays listed but loses its content, so the list never lies to you about what can be restored.
Files never travel through our API. The client asks for an upload grant that is short lived and scoped to that deployment, then writes to storage directly. The file count and the total size are checked when the grant is issued, not after the bytes have landed.
Directory requests resolve to that directory’s index document. A site can opt into single-page-app fallback, where an unmatched path resolves to the root document instead of returning an error. Content is served over HTTPS only; plain HTTP is redirected, never served.
Domains and DNS
Register a domain here, transfer one in, or attach one that stays registered elsewhere. Attaching keeps your current registrar. Transferring in makes us the registrar. Both give you the same DNS management.
You are the registrant. We transmit the contact data you enter to the registry and are not ourselves the owner of your domain. What the registry publishes about you depends on the top-level domain and on whether you are a person or an organisation, and the console states which of the two applies before you agree to anything, not afterwards in a general terms document.
Moving a domain is the moment records get lost, because nobody outside a zone can enumerate it. Before you switch the nameservers, the console probes public DNS for your current records and prefills the record table. Nothing is written until you save, so what you are looking at is a diff you can correct. It has limits, and the page names them: unusual subdomain names are not found, TTLs are not readable, and a proxied name resolves to the proxy.
Every record in a managed zone has an owner: you, or a named platform feature. Platform-owned records are visible but not editable, and they appear or disappear only when you enable or disable the feature that owns them. Enabling a feature whose records would collide with yours fails and names the collision. There is no silent overwrite.
Mail forwarding
Off by default. While it is off, the MX records belong to you and we receive no mail for your domain.
Turning it on transfers the records needed to receive mail to us, and gives you a catch-all or named aliases that forward to a target address. A target is inert until its owner acts on a confirmation message, so nobody can point your mail at an address they do not control.
A forwarded message is re-authenticated as coming from us, with the original sender kept as the reply address. That means you never publish sender authentication records for us on your domain, and it also means we cannot send mail as your domain. Both halves of that trade are deliberate.
Sending reputation is tracked per account. One account’s damage does not degrade delivery for anyone else, and an account that breaches the policy has its forwarding paused rather than being allowed to take the platform’s reputation with it. Messages with a positive spam or malware verdict are discarded, and the discards are counted and shown to you, so silence is distinguishable from loss.
The API
Every capability above is an API endpoint, and the console calls those same endpoints. There is one deliberate exception: retrieving the auth code that transfers a domain away requires an interactive session with a recent re-authentication, and no API key can reach it. Domain theft cannot be undone, so that endpoint is the one place where convenience loses.
API keys carry scopes. Secrets are stored as one-way hashes, so a lost key is replaced, never recovered. Every mutating domain operation takes an idempotency key, and a replay returns the original outcome instead of repeating the side effect, because a duplicate registration is money you cannot get back.
Operations that cannot finish inside one request return an identifier and put the state on the resource itself. Clients poll the resource, not the operation, which is what lets an infrastructure-as-code provider converge without keeping operation handles between runs.
What mosswood is not
- It does not run your code. There is no application runtime, no database, no container. It serves files, and it is priced to serve files.
- It does not negotiate. Every account gets the same rate table.
- It does not hold your domain hostage. The auth code is yours on demand, and a transfer away is a normal operation rather than a support ticket.