Privacy Policy

Last updated 4 November 2026

This Privacy Policy explains how Code Snippets B.V. (“we”, “us”, “our”) collects, uses, shares and protects personal data in connection with YOLO Cloud (the “Service”). YOLO Cloud is a Code Snippets product. It has two parts: tools to manage WordPress sites that run the YOLO plugin, and YOLO CMS, which lets your own AI build and keep a website for you.

We aim to comply with data-protection laws wherever our users are, including the EU General Data Protection Regulation (GDPR), the UK GDPR and Data Protection Act 2018, and the California Consumer Privacy Act as amended by the CPRA (CCPA/CPRA). Where a right or term applies only in your region, we say so.

How YOLO Cloud differs from the plugin. The YOLO plugin is self-hosted, and when you use it on its own we never see your site, token or AI conversations. YOLO Cloud is a hosted service: to manage your sites for you it necessarily stores some of that data (your site addresses, an encrypted access token, backups you ask for) and processes your AI messages. This policy is explicit about exactly what that means.

Two roles. For your own account, and for how you use the Service, we decide what is collected and why: we are the controller. For the personal data inside your websites (your WordPress sites’ backups, and the messages, accounts and bookings of your YOLO CMS site’s visitors) you decide, and we process it on your behalf: you are the controller and we are your processor. Section 3 covers the second role. The YOLO Sentinel Hive is different: for the attacker addresses it shares between sites, we are the controller (section 4).

1. Who we are

The data controller is Code Snippets B.V., a company registered in the Netherlands. Privacy contact: [email protected] (or via codesnippets.pro/contact). Registered address, KvK and VAT numbers are available on request and will be listed here once finalised.

2. The personal data we collect, and why

Your account

When you create an account we collect your email address and a securely hashed password (bcrypt; we never store your password in plain text), and, if you give them, a display name and a profile picture. If you sign in with Google or GitHub, we receive from that provider your email address, your account identifier there and your name, and keep the identifier and email address to recognise you; if you haven’t set a display name, we use that name as your display name. If you turn on two-factor authentication, its secret is stored encrypted (AES-256-GCM) and its recovery codes are stored hashed. If you invite people to your team, we store their email address to send and track the invitation. Legal basis: performance of a contract.

Connected sites and access tokens

For each WordPress site you connect we store its URL, the access token the YOLO plugin issues us, and capability metadata the plugin reports. Tokens are envelope-encrypted with AES-256-GCM before they reach our database, are never displayed back, 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. Legal basis: performance of a contract; our legitimate interest in operating the Service securely.

Operational data

We record the management actions you trigger (updates, activations, backups, recovery and similar), an audit log of changes made in your account, and the results of uptime, security and performance checks, so we can show you status and history and support you. To check for known vulnerabilities we send the names and versions of your sites’ plugins and themes (no personal data) to wpvulnerability.net and WordPress.org. Performance tests send your site’s address to Google PageSpeed Insights. Our own screenshot service takes pictures of your sites’ pages when you use features that need them (for example before-and-after pictures of an update, or previews of a YOLO CMS site), and we store those pictures. The before-and-after pictures of an update are kept for 90 days and then deleted automatically. Legal basis: legitimate interest in providing and securing the Service.

Backups of your WordPress sites

When you back up a WordPress site through YOLO Cloud, we store a copy of its database and files. Full backups are encrypted on your site before upload; incremental backups are not encrypted (stored as-is, partly compressed) and kept in our EU storage. That copy contains whatever your site holds, which may include its visitors’ personal data; we hold it for you as your processor (see section 3). Removing a site from YOLO Cloud deletes its backups (for a site we host, when the hosting ends); incremental data it shared with your other sites is freed once they no longer use it.

AI features

When you use the AI Bridge, Ask your fleet or a playbook, we store the messages, any images you attach and the results, so you can resume them. A conversation in the AI Bridge or Ask your fleet is kept until you delete it, or for 12 months after its last message, after which it is deleted automatically. A record of how much AI each request used (its size and cost, not its content) is kept so we can track and limit AI spending. To produce answers, your messages, images and the site information the AI needs are sent to our AI provider, Anthropic. Anthropic also powers features that run on your behalf: triage of errors on your sites and proposed fixes, safety scans of extensions shared in the Library, and the safety check and visual review of YOLO CMS sites (which send the site’s text and pictures of its pages). Search in the Library sends the text of published Library extensions to OpenAI to build a search index, and the words you type into Library search to OpenAI to match against it. If you add your own OpenAI or Unsplash key to make or find pictures, your requests are sent to that provider under your key. Legal basis: performance of a contract; your consent when you choose to use an optional feature.

Email

We send account and service email (sign-up, password reset, alerts and reports you choose) through a mail server we run ourselves. If you use email replies in the YOLO CRM extension, replies sent to your reply address pass through an email-routing service run for us by Cloudflare and are held, encrypted, in our backup storage until your site collects them, and for no more than 72 hours.

Visitors to yolo-plugin.cloud, and logs

Our servers record technical data such as IP address, browser and device type and pages viewed, to keep the Service secure. The sign-in and sign-up forms use Cloudflare Turnstile to check that a person is signing in; it receives your IP address. We do not use advertising tools, or any third-party analytics, on yolo-plugin.cloud. Legal basis: legitimate interest.

Page-view statistics

To see how many people visit yolo-plugin.cloud and use YOLO Cloud, and which pages they find useful, we count page views ourselves. This is first-party and cookieless: no cookie is set, nothing is stored on your device, and no outside analytics company is involved. For each page view (on our public pages and in the signed-in app, but never the admin area) a small script on the page tells our own server which page was viewed, and we record:

• the time, to the minute, and the page’s address, without its query string (except any campaign tags, utm_source, utm_medium and utm_campaign); in the app, the parts of an address that would name a site or other item are removed;
• the name of the website that linked to the page, if any (its host name only, such as google.com);
• your country, as Cloudflare reports it;
• the kind of device (mobile, tablet or desktop) and browser family (such as Firefox), worked out from your browser’s user agent, which is then discarded;
• whether you were signed in (yes or no), but not who you are;
• a pseudonymous visitor identifier that changes every day, so a visitor can be counted once a day.

The identifier changes every day.Our server makes it from your IP address and browser user agent mixed with a random value that is replaced every day. Each day’s random value is deleted as soon as that day is over, and is never included in our backups, so a past day’s identifier can’t be worked out again from an IP address, and page views on different days can’t be linked to each other. We never store your IP address, your full user agent, or your account with these statistics.The identifier is pseudonymous rather than anonymous: within a single day, the page views it ties together could in principle be matched to a person using other information (for example our servers’ security logs), so we treat these records as personal data, keep them briefly and use them only for counting.

When you create an account, we add one to a count of sign-ups for the website or campaign you arrived from that day. The counts are stored by day but only ever shown by whole week, and a source is only shown once at least three sign-ups came from it. (Where you came from is also kept with your new account: see the next part.)

Visitors whose browsers send Do Not Track or Global Privacy Control are counted in the same way: what is recorded is the same pseudonymous, day-limited information, never your IP address, user agent or account. Detailed page-view records are deleted after 60 days. After that only daily totals are kept (such as how many visitors a page had on a day), which is what we compare with the same period a year before. Legal basis: legitimate interest in understanding and improving the Service.

How you use YOLO Cloud, once you have an account

When you have an account, we also keep a record about you, as a signed-up user, of how you get on with the Service. It is linked to your account and used only by us, to improve the Service and to help people succeed with it (for example, to see where new users get stuck, or to offer help to someone who has stopped using it). We record:

• Where you came from when you signed up: the website that linked to us and any campaign tags (utm_source, utm_medium, utm_campaign), and the first page you saw, all taken from that day’s page-view statistics at the moment you sign up. Only these few details are copied to your account. Your page views from that day stay in the statistics without your account, but because the landing page and referrer are stored with it, they could be matched to that day’s page views for as long as those are kept (60 days). Visits on earlier days can’t be linked to you. If several people share one internet connection and the same browser, one of them could, rarely, be given another’s source.
• When you use YOLO Cloud: the days you use the app while signed in, and when you were last active in the app (updated at most every few minutes) or through an AI app you connected to YOLO CMS (which we already record for the connection itself).
• Milestones: the first time you reach steps such as confirming your email, connecting or hosting a site, making or publishing a YOLO CMS site, connecting an AI app, using the AI Bridge, your first backup, your first update run from YOLO Cloud, your first playbook, and inviting a teammate. Some are worked out from records we already keep for the Service (for example who added a site, and when). A step is credited to the person who did it when that is recorded; when it isn’t (a scheduled backup, or a site whose connection doesn’t record who started it), it is credited to the workspace’s owner.
• Which areas you use: how many pages you viewed in each area of the app (such as Sites, YOLO CMS or the AI Bridge) each day, never the full address or which site you looked at.

This record is kept while your account exists. The day-by-day detail (the days you were active and the areas you used) is deleted after 13 months; your sign-up source, milestones and when you were last active are kept until your account is deleted. Deleting your account deletes all of it. It is never shared with anyone else or sent to any third party. Legal basis: legitimate interest in running, improving and supporting the Service you signed up for. Because this is part of providing the Service to you, it isn’t changed by Do Not Track or Global Privacy Control. You can object to it, or ask us to delete it, at [email protected].

Payments

YOLO Cloud does not take payments today. If we introduce paid plans, we will update this policy, naming the payment provider, before you are asked to pay.

3. Data in your websites: YOLO CMS and backups

The website owner is the controller. If you build a website with YOLO CMS, you decide what it collects from its visitors and why, and you are responsible to them for it. We store and process that data only to run your site, on your instructions, and for no other purpose. If you are a visitor to a YOLO CMS website, please contact that website’s owner about your data; if you contact us instead, we will pass your request to them.

What a YOLO CMS site may hold

Depending on what its owner builds, a site may hold:

• Form messages: what the visitor typed and when, with a keyed one-way hash of their IP address (used against abuse), never the address itself.
• Visitor accounts: email address, name, a hashed password (never the password itself), and when the account was made and last used.
• Records visitors add: such as bookings, listings, entries or quiz answers, with the account that added them.
• Photos members add: stored as fresh copies drawn from the pixels, without the original file’s metadata (such as where a phone photo was taken).
• Payment records, if the owner connects their own Stripe account: what was paid for, the amount and its status. Card details are entered on Stripe’s own page and never reach us. Stripe is the owner’s provider, under the owner’s agreement with Stripe.
• Emails to visitors (confirmations, reminders, password links): sent through the owner’s own email account if they connect one, or otherwise through our mail service, which keeps a short record of each message (for 14 days) to handle delivery problems and limits.
• Technical logs of the changes the owner’s AI makes, kept to a fixed length. They do not hold the content of visitors’ submissions.

Where it is kept

Each YOLO CMS site has its own database on our servers in Germany (see section 6). Form messages are kept in our main database, also in Germany. Pictures and photos are kept in Cloudflare R2 storage. Backups are kept in Hetzner Object Storage in the EU.

On a visitor’s device

A visitor who signs in to a YOLO CMS site gets one cookie, __Host-yc_session, which keeps them signed in for up to 30 days and cannot be read by scripts on the page. Fonts are fetched by the visitor’s browser from Bunny Fonts (fonts.bunny.net). Forms on the platform’s own addresses use Cloudflare Turnstile to check the sender is a person; on the owner’s own domain the owner may choose their own captcha provider. Analytics are off unless the owner turns them on. Plausible, which sets no cookies, then runs for every visitor; Google Analytics and Tag Manager load only after the visitor accepts them in a notice, and that choice is remembered in the visitor’s own browser.

How long it is kept, and deletion

• Form messages are kept until the owner deletes them, or for a keeping time the owner sets (from 1 to 120 months), after which they are deleted automatically.
• Visitor accounts are kept until the owner deletes them. Records are kept until the owner deletes them or, where the site allows it, the visitor deletes their own.
• Some working records are trimmed automatically: payment notices after 60 days, automation records after 30 to 40 days, and logs by length.
• We keep the 30 most recent backups of each site, so the owner can put the site back as it was.
• When an owner deletes a site, its database, its media, its members’ photos and the preview pictures of its design choices are deleted with it (a media file that another of the owner’s sites also uses is kept for that site). A final backup is taken first. The site’s backups are kept in our backup storage for 30 days, so that a mistaken deletion can be undone if the owner asks us, and are then deleted. Members’ photos and design preview pictures are not in the backups, so they cannot be brought back. The owner can ask us to delete the backups sooner at [email protected]. The backups of a site deleted before 17 October 2026 are kept until the owner asks us to delete them.

Your AI app

When you connect an AI app (such as ChatGPT) to your site, whatever that app reads from or writes to your site through the connector is also processed by that app’s provider, under your own agreement with them. You can see which apps are connected, and disconnect any of them, in YOLO Cloud.

Help with your own privacy notice

YOLO CMS can draft a starting privacy notice for your site from what the site does, with the parts only you can answer marked. It is a starting point, not legal advice: you are responsible for checking it, completing it and keeping it accurate.

4. The YOLO Sentinel Hive

Here Code Snippets B.V. is the controller, not the site owner’s processor. The YOLO Sentinel Hive helps sites recognise known attackers. A site can take part when it runs the Sentinel extension, its owner has switched on sharing with the hive, and its workspace has the hive. Such a site reports the addresses of visitors Sentinel judged to be attacking it. YOLO Cloud scores each address across independent site owners and sends a watch list of high-scoring addresses back to the sites taking part. A workspace’s own sites also share what they detect with each other: those entries go only to that workspace’s own sites, never to another workspace’s, and a site that moves to another workspace is sent a fresh list. An address that fewer than two checked owners have reported is sent to other workspaces’ sites only if one of those owners’ workspaces has passed our trust check (through its plan or our own approval) and their site has earned enough trust, from how long it has been connected and how its reports have held up. Its score is then capped at 69, which on its own is below the scores at which Sentinel slows a visitor down or blocks them. Each site decides what to do about an address on the list, under its owner’s settings. YOLO Cloud may first score reports without sending any watch list, to test the hive.

What a report holds

• the attacker’s IP address (an IPv4 address, or for IPv6 the /64 block it uses) and its network (the block of nearby addresses around it);
• the kind of attack (such as password guessing, probing the site for weak spots or exposed files, abusing its API, fake sign-ups, scraping, card testing, a visitor pretending to be a search engine, floods of password-reset requests or searches, or guessing coupon codes), the site’s scores for it, the alert threshold the site used, its AI check’s verdict if there was one, how many events were involved, and whether a trap on the site caught it;
• when the attack was first and last seen, and when the report was made;
• a reference code for the site’s incident that does not reveal its details, and an identifier for the report;
• whether the site’s owner agreed with the report, or withdrew it as a false alarm, and whether it is a test report.

We also record which site and workspace sent each report, and whether the address was already on the site’s watch list, so we can score fairly and stop a site that misreports. Sentinel is built to leave out usernames, email addresses, page addresses (URLs), browser details (user agents), form data, page content, coupon codes, search terms, and anything about the site’s own users or trusted devices. A report of a visitor pretending to be a search engine says only that the visitor claimed to be one and did not pass Sentinel’s check; its browser details are not sent. YOLO Cloud refuses any report with a field not listed above, and checks each field’s type and size, so a report cannot bring in any of this text. If a report is wrong, the site’s owner can withdraw it, and it then stops counting.

What other sites see

For each address or network on the watch list: its score, the kinds of attack, when it was last seen, whether a trap caught it, and how many independent, checked site owners’ reports counted towards it (1 for an entry from the site’s own workspace or from a single checked owner); and the addresses taken off the list. Never which sites or workspaces reported an address. Entries on a workspace’s own list come only from that workspace’s own sites, so they can show those sites that one of their own sites reported the address, but the entry does not say which one. The sites taking part may be hosted anywhere, so the watch list can be sent outside the EU and the UK (see section 7).

Why, and the legal basis

We use this data only to help keep websites secure: network and information security. Legal basis: legitimate interests, ours and those of the sites taking part (UK and EU GDPR Article 6(1)(f); Recital 49 names this purpose).

Where it is kept, and for how long

Hive data is stored on our database server in Germany, in the EU. No customer, visitor or site taking part can read what we store: only our own systems and administrators can. The sites taking part receive only the watch list described above. Each period below ends at a daily clean-up, so data can last a little longer than the period shown.

• Reports: 7 days from the last time we receive them (a report the site updates, for example when its owner reviews it, is kept 7 days from that update), and never more than 30 days after we first receive it. Reports of attacks first seen more than 30 days earlier are refused and not stored. A site’s reports are usually deleted sooner if its owner switches sharing off or its workspace no longer has the hive.
• Scores: removed once the address has not been seen for 30 days, and usually sooner, when they fade or no report from the last 7 days remains. A note of the removal, holding the address, is kept for up to 7 more days so that the sites taking part remove it too.
• Confirmations (a record that a site later saw an attacker already on its watch list): 90 days. They hold only a keyed one-way hash of the address, never the address itself.
• Owners’ verdicts on reports: 90 days, without the address.
• Our audit log of the actions our team takes on the hive: 1 year. It holds an address only when someone has objected, or we added or removed an excluded range by hand.

Update signals (the bad-update alarm)

A site taking part in the hive can also report that a plugin or theme began behaving in a new way soon after it was updated, if its owner’s Sentinel settings allow it. Each signal holds: the plugin or theme and its version; when the site updated it (if the site saw that) and when it first saw the behaviour; the kind of behaviour (it began contacting a new outside domain, its files differ from the copy published on WordPress.org, it added a new scheduled task, or it placed code somewhere unusual); and one detail for that kind. For a new domain, that is the domain’s registrable name: for ordinary domains such as example.com only that, never the full address; for a shared platform such as workers.dev or github.io, the name that platform gives its customer (such as acme.github.io); and whether a subdomain was used. For the other kinds: how many files changed or were added (never their names), the scheduled task’s name, or which kind of unusual place. Signals hold no visitors’ addresses or other personal data, and Sentinel is built not to send a domain that the site’s owner entered into the plugin’s own settings. We record which site and workspace sent each signal, so that each owner counts only once. If the owner marks a signal as expected, it stops counting. A domain name we can’t accept (which can be a full address, such as one of a domain’s subdomains) is kept, with the workspace that sent it and its site that last sent it, until 14 days after that workspace last sent it, so that we notice a fault in our list of domain suffixes.

We use signals only to spot a plugin or theme update that may have been compromised, from the same new behaviour appearing on many unrelated owners’ sites soon after its release (legitimate interests: network and information security). Signals are not sent to other sites. A person on our team reviews every alarm before any owner is told. If we confirm one, we email the people who receive security alerts for each workspace with a site we see running that version (for a theme, the sites that reported it), about their own sites only, and never say which sites reported it. We keep a record of each warning: which workspaces and which of their sites, which version, how many people, and a keyed one-way hash of each address we sent it to (never the address itself), recorded as each email is sent, so that no one is emailed twice (unless recording a send itself fails, when that one person may get it again). For a theme, and for a plugin on a site that isn’t in our record of its plugins, the sites we warn are the sites that reported it, so for those this record also shows which workspaces’ sites reported it. We may also report the release to its author and, for plugins and themes on WordPress.org, to WordPress.org’s security team, without saying which sites reported it.

• Signals: never more than 14 days from when we first receive them. They are deleted sooner: once we next hear from the site after its owner switches sharing off, and at a daily clean-up once its workspace no longer has the hive or the site moves to another workspace.
• Alarms (the count of owners for a version and kind of behaviour, its detail, and our review): 30 days after the last signal received for it; an alarm awaiting our review may be kept a few days longer until we review it; a confirmed alarm 1 year. Which workspaces reported is kept with the alarm for at most 30 days after its last signal.
• Our record of the warnings we sent (which workspaces and which of their sites, about which version, how many people, and the keyed hashes; for a theme, or a plugin on a site not in our record of its plugins, those sites are the ones that reported it): 1 year.

Deleted hive data, including signals and alarms, can remain in our database’s backup copies for about a week.

Your rights

Anyone can ask us whether their IP address is held in the hive, and object to it, at [email protected]. We will tell you whether it is held, its score, the kinds of attack and the dates. We will tell you that the source is sites taking part in the hive, but not which sites or workspaces reported it. If you object, we put the address on an exclusion list for 90 days: it is taken off the watch list (once the hive is running, if it is paused) and reports of it are no longer scored. Reports of it that still arrive are kept, unscored, and deleted like any other report (see above). We keep the exclusion, with the address, for the 90 days, unless you ask us to lift it sooner, and a record of the objection, with the address, in our audit log for 1 year.

5. Cookies

We use a small number of cookies to make the Service work: an httpOnly session cookie that keeps you signed in (for up to 30 days), short-lived cookies used during sign-in, two-factor authentication and Google or GitHub sign-in, and __Host-yc_account, which remembers which workspace you were last using (for up to a year). We do not use advertising or analytics cookies: our page-view statistics (section 2) use no cookies and store nothing on your device. You can control or delete cookies in your browser, though essential cookies are needed to sign in.

6. Who we share your data with

We do not sell your data. Our database, mail server, deployment platform and screenshot service are software we run ourselves, on servers rented from Hetzner in Falkenstein, Germany. Beyond that, we share data only with the processors needed to run the Service:

• Hetzner (Germany): the servers the Service runs on, and Object Storage in the EU for backups of your WordPress and YOLO CMS sites and for held CRM replies.
• Cloudflare: carries all traffic to yolo-plugin.cloud, so it sees visitors’ IP addresses and requests; R2 storage for uploaded pictures, website media, member photos, screenshots and plugin downloads; Turnstile, which checks that a sign-in or a form is sent by a person; and email routing for CRM replies.
• Anthropic: the AI behind the AI Bridge, Ask your fleet, playbooks, error triage and proposed fixes, Library safety scans, and the safety check and visual review of YOLO CMS sites.
• OpenAI: builds the Library search index from published Library extensions and matches the words typed into Library search against it; and makes or edits pictures only when you add your own OpenAI key.
• Google: sign-in with Google, if you choose it; and PageSpeed Insights, which receives your sites’ addresses (no personal data).
• GitHub: sign-in with GitHub, if you choose it.
• Context7: the AI Bridge may fetch public technical documentation; your site data is not sent for these lookups.
• Unsplash: stock photo search, only with your own key; it receives the search words.
• wpvulnerability.net and WordPress.org: receive plugin and theme names and versions, for security and update checks (no personal data).
• Bunny Fonts (bunny.net): serves the fonts on YOLO CMS sites, and so receives visitors’ IP addresses.
• Google reCAPTCHA or hCaptcha: only where a YOLO CMS site’s owner picks one for forms on their own domain; it receives the visitor’s IP address.
• Plausible, Google Analytics or Google Tag Manager: only where a YOLO CMS site’s owner turns analytics on (Google’s only after the visitor accepts).
• rdap.org and domain registries: receive your sites’ domain names, to check when they expire.
• A YOLO CMS owner’s own webhooks: if an owner sets up an automation that calls a web address, the records they chose are sent to that address.
• Stripe: only where a YOLO CMS site’s owner connects their own Stripe account, as that owner’s provider.

Through the YOLO Sentinel Hive we also send a watch list of attacker addresses to the sites that take part (section 4).

We do not share your data with anyone else except as needed to run the Service or as required by law.

7. International data transfers

Our servers, database and backup storage are in the EU. Some processors above (for example Cloudflare, Anthropic, OpenAI, Google and GitHub) may process data in other countries, including the United States. Where those processors transfer data outside the EU, the UK or your region, we rely on appropriate safeguards such as the European Commission’s Standard Contractual Clauses, or the provider’s adequacy or transfer framework. Separately, the YOLO Sentinel Hive’s watch list is sent to the sites taking part wherever they are hosted, which may be outside the EU and the UK (see section 4).

8. How long we keep your data

We keep your account data while your account is active. Disconnecting a site removes its stored token, and removing a site deletes its backups (for a site we host, when the hosting ends). Update screenshots (the before-and-after pictures of an update) are deleted 90 days after they are taken. AI Bridge and Ask your fleet conversations are deleted when you delete them, or 12 months after their last message. Detailed page-view statistics are deleted after 60 days, leaving only daily totals, and the random value behind each day’s visitor identifiers is deleted as soon as the day is over. The record of how you use YOLO Cloud once you have an account is kept while your account exists, its day-by-day detail for 13 months, and is deleted with your account. Data in YOLO CMS sites is kept as described in section 3, and data in the YOLO Sentinel Hive as described in section 4. To delete your account and associated data, email [email protected]. We may retain limited records where required for legal or accounting reasons.

9. Your rights

Depending on where you live, you may have rights to access, correct, delete, port, restrict or object to the processing of your personal data, and to withdraw consent. California residents have the rights to know, delete, correct and opt out under the CCPA/CPRA; we do not sell or “share” personal information as those terms are defined. If your data is held in a YOLO CMS website, the website’s owner handles these requests, and we help them do so.

10. How to exercise your rights

Email [email protected]. We will respond within the time required by applicable law. You also have the right to complain to your local data-protection authority.

11. Children

YOLO Cloud is not directed to children and is not intended for anyone under 16.

12. Security

Access tokens, recovery keys, two-factor secrets and the email and payment settings YOLO CMS owners connect are encrypted at rest (AES-256-GCM); full backups are encrypted on your site before upload, and incremental backups are not encrypted (stored as-is, partly compressed) and kept in our EU storage; passwords are hashed with bcrypt; every request is checked against your account and your role in it; and outbound calls to your sites are guarded against being redirected to internal networks. No system is perfectly secure, so we recommend you also keep your own independent backups of your sites.

13. Changes to this policy

If we make material changes we’ll update the date above and, where appropriate, notify you in the app. Questions? Email [email protected].