Rules and limits

What can go in a hotsite

Static files: HTML, CSS, JavaScript, images, fonts, PDF, JSON. The site is served as-is, with a one-week cache for media and code files. A 404.html at the root becomes the error page.

Nothing runs on the server. .php, .cgi, .py, .sh and similar files are refused at upload time, and even if one slipped through the server answers 404 for them. This is deliberate: hotsites are static. If a project needs PHP or a database it belongs on the WordPress lane on the rapadura.net multisite. See WordPress sites.

Secrets are refused. .env, keys (.pem, .key, id_rsa), .ssh and .aws folders, wp-config.php and the like block the whole publish, with the list of what was found. The fix is to publish only the build output directory, never the repository root.

Noise directories (.git, node_modules, .cache, vendor) are skipped silently.

Names

A hotsite is name.zone. Zones: rapadura.net and phpcomrapadura.org.
The name is 1 to 63 characters: lowercase letters, digits and single hyphens. No --, accents or dots.
Reserved names (www, mail, panel, agents, api, blog, admin among others) and names already used by another site on the server are refused.
A recently deleted name is held for restore; choose another.

Limits

what	default
sites per person	20
size per site	500 MB
size per file	100 MB
files per site	20,000
versions kept	20 (older ones are pruned; the live version never)

rapadura zones shows the values in force. Need more? Ask the administrator.

Security and access

Nobody gets SSH, a panel or a server password. Only the CLI.
Login is through GitHub, by invitation. Each machine gets its own token, stored in ~/.config/rapadura/credentials.json with 0600 permissions.
Tokens expire after 90 days and can be revoked at any time (rapadura logout revokes the current machine's).
You see and change only your own sites. The administrator sees all.
Every action lands in the audit log: who, what, which site, when.
Never paste your token into chat, a commit, an issue or a log. If it leaked, revoke it.

Versions and rollback

Each publish is an immutable version, numbered from 1. The switch between versions is atomic: either the whole site changes or nothing does. Before reporting success the gateway validates the configuration, reloads the server and checks that the new version is really being served. If any step fails, the previous version stays live and the error comes back to you.