Safety
Safety, end to end.
Running live WordPress sites from the cloud, with an AI helping, shouldn’t be a leap of faith. Changes are recorded and most can be undone, AI-written fixes wait for a person, and your credentials and full backups are encrypted. Here is exactly how.
Keep your own backups too
Our snapshots, auto-rollback and off-site backups are strong, but no software is infallible. Please also keep an independent backup, such as your host’s daily backups, so you always have a way back that doesn’t depend on us.
What the cloud does
Your account, credentials and backups
The safeguards on our side: around your sign-in, the keys to your sites, your backups and every request we make.
Site keys are encrypted
The keys that let us reach your sites, and their recovery keys, are encrypted with AES-256-GCM, a separate key for each record, before they reach our database. They’re never shown back to you, and are decrypted in memory only when we call your site: for something you did, or a check or schedule the Service runs for you.
Workspaces kept apart, on every request
Our server code checks every request against your workspace and your role before it reads or changes anything, on every route that touches a site. Our servers use a privileged database connection, so that check is what keeps customers apart, and our security reviews test it every time. Underneath, row-level security is switched on and the tables that hold secrets have no policy that lets anyone read them from outside our servers.
Full backups sealed before upload
Full off-site backups are sealed on your own site with your account’s public key before they’re uploaded, so storage only ever holds encrypted files. The matching private key is kept encrypted by us and decrypted only on our servers to restore a backup (or, for YOLO CMS, to undo a publish or rebuild a lost site). Incremental backups are not encrypted: choose Full where that matters.
A front door with two locks
Passwords are hashed with bcrypt. Sign-in is protected by Cloudflare Turnstile, and app-based two-factor, once on, is required every time, even through GitHub or Google. Sessions live in signed, httpOnly cookies that page scripts can’t read.
The right access for each person
Owner, admin, member and viewer roles. Viewers can see everything and change nothing: every action that writes checks the role first. Approving an AI fix needs an owner or admin, and backups and recovery stay with the workspace that owns the site, even when it’s shared with another.
Guarded outbound calls
When we call your site, we resolve its address, refuse private, loopback and cloud-metadata networks, and pin the connection to the address we checked. A hijacked hostname can’t be used to reach anything internal.
AI with rails
What the AI is not allowed to do
The limits are in code, not in a prompt.
AI fixes wait for a person
Auto-fix is off until you switch it on for a site. It proposes the safest fix it can find, then waits: an owner or admin approves, Cloud applies it through the plugin’s safety checks and confirms it worked. A daily spending cap stops it if anything runs away, and every step is logged.
The error watch only reports
It records each new fatal error, explains it and suggests a fix, such as updating the plugin that caused it. It never updates or switches off a plugin by itself: that stays your decision.
Shared code is scanned
Every extension published to the Library is scanned by AI for malicious or dangerous code and badged before anyone installs it. Nobody can republish another creator’s extension as their own, even with comments or spacing changed.
You decide the riskiest access
When you approve a site’s connection you choose what Cloud may do. Everything is ticked to start with: untick writing code and installing plugins if you don’t want them. If you don’t grant them, Cloud can’t turn them on; only someone signed in to wp-admin can. If you do, treat that as full control of the site: installing plugins also lets Cloud open wp-admin as an administrator (magic login). The emergency recovery key is only ever set up in wp-admin.
What the plugin enforces
Guardrails on every site
Some safety lives in the YOLO plugin itself, on your site. Every action from the cloud, yours or the AI’s, goes through it.
Changes are snapshotted
Before the plugin changes content, design, settings, extensions or what’s active, it records what was there. Undo puts it back; redo re-applies it.
Auto-rollback
Plugin and theme updates, activations and theme switches are health-checked against the site’s API and home page, and reverted automatically if they would take the site down. WordPress core updates are health-checked and reported.
Break-glass recovery
When a site is fully down and even wp-admin is gone, put it into safe mode from the cloud. No SSH, no host login. It needs the site’s emergency recovery key, set up in wp-admin and saved in Cloud beforehand.
Tamper-evident audit log
Every action is written to a hash-chained log you can verify. Change one row and the chain breaks, so the history can’t be quietly rewritten.
Scoped access
Each connection is scoped: read, content, design, backup, restore, code, install. A key can only reach the areas it was given, though code and install amount to full control of the site.
Secrets stay secret
When the AI inspects configuration, secret values such as passwords and API keys are never returned. It learns that a key is set, never its full value.
Responsible disclosure
Reporting a security issue
Found a vulnerability in YOLO Cloud or the YOLO plugin? Please email support@codesnippets.pro with “Security report” in the subject, rather than disclosing it publicly. We aim to acknowledge reports within a few business days, and we’re glad to credit you for responsibly disclosed findings. Our security.txt has the same details.
Run every site with a net.
Encrypted credentials and full backups, scoped access, AI fixes that wait for a person, and a way back from most changes.