What each Backoffice section and action does. Search titles and answers. This is not a traffic log and it never shows tokens or private keys.
No documentation articles match your search.
Cloudo sits in front of your website. Visitor traffic goes Visitor → Edge → Origin. The Edge is Cloudo’s public front door. The Origin is your own hosting server that actually runs the site.
You manage domains, DNS, SSL, origins, cache, and security in the Backoffice. After a successful deploy, Edges keep serving from a local last-valid configuration. Visitors do not talk to the Backoffice when they load your site.
The Control Plane is the Backoffice, the authenticated Control API, and the database that stores the source of truth. It is where you edit settings and queue deployments.
An Edge is a public server that terminates visitor HTTP/HTTPS. Authoritative DNS (`ns1` / `ns2`) is served by dedicated DNS-capable nodes. Nodes pull configuration through the Control API. They never connect to the database themselves.
Already-configured visitor HTTP/HTTPS and authoritative DNS keep working. Edges and DNS nodes continue serving the last valid local configuration. New Backoffice edits and new deploys cannot run until the Control Plane is back.
A Control Plane outage is not the same as a visitor outage. Sites that already deployed successfully stay up.
Every Edge keeps the last configuration that passed validation and activated. If a new candidate fails validation, that last valid configuration stays in place and traffic is unchanged.
Validation must succeed before activation. Edges reload services after a good activation; they do not restart Nginx for a normal deploy. A restart would drop connections and is not the deploy path.
A Config Version is a numbered snapshot of a plane (HTTP, DNS, or mail) stored in the Control Plane. Saving and deploying creates or reuses a version. Edges report the version they currently serve and the version they should serve.
Version numbers are how you compare “what is live on an Edge” with “what the Backoffice last queued.” They are not a visitor-facing setting.
A deployment pushes one Config Version to one Edge. The Edge generates a candidate, validates it, activates it atomically, reloads, and reports status. If validation fails, the previous working configuration stays active.
Save & Deploy queues work. Live visitor traffic changes only after that Edge validates and activates the new release.
Rollback re-queues a previous known-good Config Version to the Edge. It is another deployment of an older snapshot, not an instant undo on the visitor path.
The Edge still validates the candidate before activating the rolled-back version. If that validation fails, the currently serving configuration is kept.
After you submit the registration form, Cloudo emails a 6-digit code to confirm you control that email address. Enter the code on the verification page to finish creating your account. You do not need to click a link in the email when using this flow.
Each code expires after 10 minutes. Codes are single-use. Requesting a new code invalidates older unused codes for that account.
No. Expired codes, codes that were already used, and codes replaced by a newer resend no longer work. Enter the latest code from your email.
Open Profile in the Backoffice account menu. The Logged devices section lists active sessions for your account, including browser/OS summary, approximate IP, and last activity.
Yes. On Profile → Logged devices, use Sign out next to any session that is not marked Current device. That ends only that session.
It keeps you signed in on the device you are using and ends every other active session for your account. You confirm with your current password. Use this if you think an old browser or shared computer still has access.
Cloudo shows browser, operating system, last activity, and a partially masked IP from the session record. Exact city or country location is not shown when reliable GeoIP is not available for profile sessions. Approximate IP metadata is enough to recognize a device without sending your IP to third-party lookup APIs.
Starts onboarding for a hostname you control. Cloudo scans existing public DNS, then you review records and save.
When you want Cloudo to publish authoritative DNS and, after Protection and SSL, proxy HTTP through Edges.
Puts the domain under Cloudo management so later DNS, SSL, origin, CDN, and security settings can deploy.
Does not create mail, FTP, or any hosting service. Creating DNS records is not the same as creating those services.
Apex A (proxied) and www CNAME (proxied) are created automatically when missing. mail and ftp records are not auto-created. You must still point the domain’s nameservers at ns1.cloudo.lol and ns2.cloudo.lol for Cloudo DNS to be authoritative.
New domains often sit in pending while DNS is scanned, records are reviewed, nameservers are switched, and the first deploy completes. SSL can also show pending or issuing after Protection is turned on.
Pending means work is not finished. It is not a visitor outage by itself. Traffic follows whatever the Edge last activated, and public resolvers follow whatever nameservers the registrar still has.
Queues deploys that drop the domain’s configuration from Edges after you type the domain name to confirm.
When you no longer want Cloudo to publish DNS or proxy HTTP for that hostname.
Stops Cloudo from remaining the intended publisher for that domain once drop deploys succeed and you move nameservers away.
Does not instantly wipe every resolver cache, registrar nameserver setting, or last-valid Edge release.
Can interrupt visitor traffic. Edges keep the last valid release until the drop deploy validates and activates. External DNS may still point at Cloudo until you change the registrar.
Removing a domain is dangerous. It can interrupt visitor traffic once drop deploys activate. Typing the exact name is a deliberate confirmation so a misclick does not queue a drop.
Visitor traffic follows the last valid configuration already on each Edge. Editing DNS, origins, SSL, firewall, or CDN in the Backoffice does not change live traffic until a deployment validates and activates on that Edge.
While a domain is pending removal, Edges may still serve the previous release. After a successful drop, that Edge stops serving the domain. If some Edges succeed and others fail, traffic can differ by Edge.
The Backoffice stores the desired snapshot. Edges only change after a deployment of that snapshot. This keeps a failed candidate from replacing a working site: validation must succeed first, then the Edge reloads.
If you skip deploy, you have saved intent in the Control Plane but visitors still see the last activated release.
Customer-editable types are A, AAAA, CNAME, MX, TXT, and CAA. NS and SOA are not customer-editable; Cloudo publishes those for the zone.
Creating a record does not create a service. An MX record does not provision mailboxes. An A record for ftp does not create FTP.
TTL is how long resolvers may cache the record. In the Backoffice you can choose Auto or 60, 120, 300, 600, 1800, 3600, 14400, or 86400 seconds.
Lower TTL makes later changes visible sooner after expiry, but it does not flush caches that already hold the old answer.
Proxy can be enabled on A, AAAA, and CNAME records. Proxied hostnames are intended to go through Cloudo Edges for HTTP/HTTPS (orange-cloud style). DNS still publishes Cloudo addresses for those names.
Turning proxy off publishes the origin address instead of sending web traffic through the Edge. MX, TXT, and CAA are never proxied.
When you add a domain, Cloudo auto-creates a proxied apex A record and a proxied www CNAME if they are missing. mail and ftp are not created automatically.
Certificate issuance may add a temporary _acme-challenge TXT record for DNS-01. That is for SSL, not a website hostname.
Saving in the Backoffice updates the DNS records table immediately without a full page reload. A “DNS changes pending” notice means the change is saved but not yet live on authoritative DNS until deploy finishes.
Saving in the Backoffice is not the same as every resolver on the internet updating. The change must deploy to Cloudo’s authoritative DNS nodes (`ns1` / `ns2`), then public resolvers wait until their cached TTL expires.
Your ISP or browser may still show the previous IP for minutes to hours. Check from more than one resolver, and confirm nameservers at the registrar are ns1.cloudo.lol and ns2.cloudo.lol.
An origin is your backend server for a domain — the machine that generates HTML and application responses. It is not an Edge node. Edges proxy visitors to the origin; they do not host the site for you.
Each origin has an address (IP or hostname), a port, and a protocol (HTTP or HTTPS) for the Edge-to-origin connection. That protocol is independent of the visitor-facing HTTPS only toggle.
Wrong port or protocol commonly produces 502 or 504 for visitors after deploy. Confirm the origin actually listens on that combination and allows the Edge addresses.
Host header and SNI are separate origin fields. Host header is what the Edge sends in the HTTP Host header. SNI is the name used on the TLS handshake when the origin protocol is HTTPS.
If the origin virtual-host or certificate expects a specific name, set these fields to match. Leaving them wrong can look like an origin outage even when the IP is reachable.
A domain can have more than one origin. Pool modes are single, round_robin, least_conn, and primary_backup (shown as Round robin, Least connections, and Primary + backup).
Changing pool membership or mode does not affect visitors until an HTTP deploy activates.
Origin health in the Backoffice is monitoring. It tells you whether Cloudo could reach the origin recently. It is not a silent traffic switch by itself.
A red or failing health badge is a signal to check the origin. It does not rewrite DNS and it does not replace Save & Deploy.
CDN caches static files at the Edge: css, js, images, and fonts. HTML is not cached. POST requests, Authorization headers, and login cookies bypass cache.
This is optional static file caching on the Edge, not a global anycast CDN product. Objects larger than 512 MiB are not stored. Cached objects are valid for 7 days of inactivity. There is no TTL slider in the UI.
Toggles “Cache static files (css/js/images/fonts)” on the domain CDN page and queues an HTTP deploy.
When you want Edges to store static assets, or when you want every static request to go back to origin.
Can reduce origin load for cacheable static files after the deploy activates.
Does not cache HTML. Does not change origin files. Does not create extra Points of Presence.
Save & Deploy must succeed on each Edge. Until then, the previous cache setting remains live.
Bumps the cache generation for the domain and queues a new HTTP config so Edges drop cached static files for that domain.
When visitors still see an old css/js/image/font after you updated the file on the origin.
Forces those static URLs to be refetched from origin after the deploy validates and activates.
Does not delete files on the origin. Does not require remote shell access to Edges. Does not call a separate Edge purge API. Does not reset HTML (HTML is not cached).
Nginx is reloaded, not restarted. You must type through the confirmation. Origin traffic for static files will rise until the cache fills again.
When static cache is on, responses can include X-Cache with HIT, MISS, BYPASS, EXPIRED, or STALE.
Customer certificates use ACME DNS-01. Cloudo publishes an _acme-challenge TXT record on the authoritative nameservers, the certificate authority checks it, then the certificate is stored and deployed to Edges.
Nameservers must be ns1.cloudo.lol and ns2.cloudo.lol for DNS-01 to succeed. Turning Protection ON prepares a certificate automatically. Certificate secrets are never displayed in the Backoffice.
Pending or issuing is normal while DNS-01 runs and while the certificate is deployed. It does not always mean the site is down. If a previous certificate is still valid, visitors can keep using HTTPS on that last valid certificate.
If nameservers are not on Cloudo yet, or _acme-challenge cannot be seen publicly, issuance stays pending or fails.
Cloudo renews certificates before they expire using the same ACME DNS-01 path. You do not upload files to Edges. Failed renewal keeps the last valid certificate until it expires.
Watch SSL status and expiry on the domain SSL page. Do not delete the domain to “force” renewal.
When On, visitors who request HTTP are redirected to HTTPS. Origin protocol is still configured under Origins.
When you want all visitor traffic on HTTPS after a certificate is active.
Avoids lingering HTTP for visitors once HTTPS is working.
Does not issue a certificate by itself. Does not change the origin’s HTTP vs HTTPS setting.
Queues an HTTP deploy. If HTTPS is not active yet, forcing redirect too early can make HTTP users fail to upgrade cleanly.
Failed issuance keeps the last valid certificate on the Edge if one exists. The site does not automatically fall back to a blank or self-signed cert from this failure path.
Check nameservers, DNS deploy status, _acme-challenge, and the certificate error on the SSL page. Fix the cause and retry. Do not restart Nginx from the Backoffice — there is no such button, and normal deploys reload only after validation succeeds.
Domain Security covers DDoS Protection (automatic and manual Layer 7 mitigation), firewall rules, rate limiting, and related Edge enforcement. Human Verification is the shared browser-challenge engine used by DDoS Under Attack / Automatic escalation and by firewall or rate-limit Managed Challenge actions — it is not a separate top-level product. IP Lists are account-level reusable lists you can attach from firewall conditions.
These tools run on the Edge at request time. They are not a web application firewall that inspects SQL or scripts inside POST bodies. There is no SQL injection, XSS, or brute-force product in the Backoffice.
Human Verification is Cloudo’s shared browser-challenge engine on the Edge. It is not configured as a standalone Security product. DDoS Protection (Automatic escalation and Under Attack), firewall Managed Challenge, and rate-limit Challenge all reuse the same engine, cookies, and passage duration.
When a browser must complete the check, a normal visitor is not held for 30 seconds. The page usually finishes in about 1–2 seconds (Managed Challenge proof-of-work difficulty 3), sets a verification cookie, and continues. Under Attack uses a harder proof (difficulty 5) that can take longer but stays bounded. If the check cannot finish within about 8 seconds, it stops and shows a retry — it does not keep spinning until a long timeout.
Challenge start and complete use internal /__cloudo/* locations that turn off recursive auth_request and do not apply visitor DDoS or rate-limit zones. Those paths talk only to the local verifier; they do not bypass protection on normal customer URLs.
A successful complete sets the HttpOnly __cloudo_verified cookie (Secure on HTTPS, SameSite=Lax). Later requests with a valid cookie pass auth without repeating the challenge until passage TTL expires. Challenge passage (how long a visitor stays verified) is set on Domain → Security → DDoS Protection. Default is 30 minutes. Protection must be ON for challenges to affect visitors.
If a challenge feels slow: confirm Managed Challenge vs Under Attack, check that /__cloudo/challenge/start and /complete respond quickly, and ensure the browser is not blocked from running the challenge script. This is application-layer (HTTP) mitigation on Cloudo Edge. It does not replace provider-level volumetric L3/L4 DDoS protection.
Limits how many HTTP requests a client IP can make to a path (optional trailing /*) during an interval, per Edge. Action is Block (typically 429 Too Many Requests) or Managed Challenge. Duration is an extra ban window in seconds after a Challenge limit is exceeded; 0 means no extra ban beyond the interval.
Login, search, and API paths that should not accept unlimited attempts from one IP.
Credential stuffing, abusive crawlers, and simple Layer 7 request floods against a path.
Distributed floods from many IPs, volumetric DDoS, and slow connection exhaustion (that is connection limiting). Limits are per Edge, not a global cluster counter.
Legitimate users behind a shared NAT can hit 429. Aggressive limits break APIs. Warning: This action can interrupt visitor traffic.
Connection limiting is not a UI editor. Customer sites have a baseline of 64 concurrent connections per client IP on the Edge. You cannot tune that number in the Backoffice.
This is separate from rate-limit rules. Hitting the connection ceiling looks like errors or stalled requests, not a Backoffice “connection limit” page.
Each rule has an action (allow, block, or Managed Challenge) and conditions: country, IP, CIDR, hostname, path, and/or method. Lower priority numbers are evaluated first. The stored action value for Managed Challenge remains `challenge` for compatibility.
Rules compile onto the Edge and take effect after deploy. An allow that matches stops later block/challenge from applying to that request. A mistaken allowlist or deny can lock out real users or staff.
Lets matching requests skip later firewall deny/challenge for this rule set.
When you need a known office CIDR, IP list, or path to pass while other traffic is challenged or blocked.
Keeps trusted clients from being blocked by later rules.
Is not an “IP list is an allowlist” by itself. IP lists only store addresses until a rule uses them.
Too-broad allows (whole countries, 0.0.0.0/0) weaken later blocks. Deploy required.
Denies matching requests (typically HTTP 403).
When you need to refuse a country, CIDR, path, or method after deploy.
Stops matching visitor requests from reaching origin.
Does not stop volumetric floods that saturate the uplink before Nginx. Does not replace origin firewalls.
Can interrupt real traffic if conditions are too wide. Live change only after a successful HTTP deploy.
Sends matching requests through the shared Human Verification engine instead of a hard deny.
When you want suspicious traffic to prove it is a browser without immediately 403ing everyone.
Reduces automated hits that cannot complete the challenge.
Does not replace rate limits. Does not inspect application payloads.
Real users must complete a short browser check (normally 1–2 seconds, not a 30-second hold). Combined with DDoS Under Attack it can feel heavy. Deploy required.
IP Lists are reusable collections of IPs and CIDRs at account level. A list is not an allow or a block by itself. Firewall rules (or other attachments) decide the action.
Edit the list, then ensure a rule references it, then deploy the domain security snapshot. An empty or wrong list can allow or deny the wrong people.
Country conditions use Edge GeoIP. It is approximate. Some visitors are classified as XX (Unknown). XX never matches a real country rule, so “block Greece” will not match Unknown, and “allow only US” will not allow XX.
VPNs, mobile carriers, and anycast clients are often mislocated. Treat geo rules as coarse, not legal-grade location.
DDoS Under Attack, Automatic escalation during an attack, a firewall Managed Challenge action, or a rate-limit challenge can show a JavaScript/browser check. Bots and clients that do not run it fail or retry.
A real browser is not paused for 30 seconds. The check normally completes in about 1–2 seconds, then the Edge issues a cookie and sends the visitor back to the page they requested. If verification cannot finish within about 8 seconds, the page shows a retry instead of waiting longer.
If everyone is challenged, check DDoS Protection mode and firewall/rate-limit rules. Leave Under Attack when the attack ends, or add an allow for known office IPs, then deploy.
DDoS Protection is Cloudo’s unified HTTP / application-layer mitigation on the Edge. Modes: Automatic (default), Standard, and Under Attack. (High remains available for existing configurations.)
Automatic keeps standard protection and escalates locally on the Edge when sustained abnormal traffic is detected. Configured mode stays Automatic; only the effective Edge mitigation state changes. Escalation may temporarily apply managed challenges, rate limiting, or blocking.
Standard keeps baseline protections without automatic aggressive Human Verification. Explicit firewall or rate-limit Managed Challenge rules still work.
Under Attack enables aggressive temporary L7 protection and uses the shared Human Verification engine for browser traffic. Legitimate visitors may be challenged. Prefer Automatic unless you are actively under attack.
Challenge passage on the same card sets how long a visitor remains verified after completing a challenge (default 30 minutes). Configured mode and effective Edge mitigation are separate concepts.
Save draft stores mode and challenge passage in the Control Plane only. Save & Deploy stores those settings and queues the normal Edge config deployment. Live visitor mitigation changes only after each Edge validates and activates the new release. If a deploy fails validation, Edges keep the previous working configuration.
Cloudo protects traffic that reaches Cloudo Edge nodes (application-layer / L7). Very large network-layer volumetric attacks that saturate uplink capacity need upstream/provider mitigation. This is not unlimited DDoS protection.
If the Control Plane is offline, Edges keep serving with their last valid configuration and local protection. Automatic mitigation waits for traffic to stay normal for a cooldown before relaxing, to avoid flapping.
Recent attack events appear on Domain → Security → DDoS Protection. SSL, ACME, and existing cache bypass rules are unchanged by DDoS settings.
No. The Backoffice does not offer SQL injection, XSS, or brute-force signatures. Firewall and rate limits match request metadata (IP, country, host, path, method, rate), not application payloads.
Application hardening still belongs on the origin.
Analytics shows time-bucketed HTTP requests and DNS queries for managed domains. HTTP includes Cache HIT %, Origin %, status classes (2xx / 3xx / 4xx / 5xx), estimated Unique Visitors, countries, hostnames, methods, and paths.
The DNS tab loads DNS query volume and DNS breakdowns (name, type, record, country, node). Unique Visitors and HTTP path/status cards are calculated on HTTP Traffic and Overview. Security counters are calculated on Overview and Security. The DNS tab does not calculate those HTTP-only figures. Analytics page numbers can lag up to about 30 seconds because the page caches and refreshes on that interval. An open drill-down panel keeps the rows from its last load until you change its filters, change page, or open it again — the main charts still refresh on the 30-second poll. The home Dashboard 24h HTTP/DNS/blocked/average-response cards use a separate cache of about 45 seconds and do not calculate Unique Visitors. The origin map does not make a second Analytics request.
Blocked requests on Dashboard and Analytics open a detail drawer (same API). Aggregate cards stay on rollups; per-request reason detail loads only on open. See Blocked requests drill-down.
There is no general visitor IP panel and no Bandwidth card. Serving does not depend on this page. If Analytics is slow or empty, Edges can still be serving traffic.
Unique Visitors is an approximate count of distinct client IPs for the selected range. The Edge updates a privacy-preserving HyperLogLog sketch in memory, then discards the raw IP before aggregation. Control Plane never stores visitor IPs for Unique Visitors — only mergeable sketches. Separately, blocked-request detail rows may retain client IPs for investigation (limited retention); that is not used for Unique Visitors.
The figure is shown on HTTP Traffic and Overview. The DNS and Security tabs do not calculate Unique Visitors.
The figure is an estimate, not a guaranteed unique-human count. Shared NATs, CGNAT, VPNs, and rotating IPs can under- or over-count relative to people.
HTTP status is not the same as a Security action. An origin can return 403 or 429 without Cloudo counting a Firewall Block or Rate Limit Block. See Security counters in Analytics.
The Security tab counts the effective Cloudo decision for each HTTP request from Edge access-log fields (nginx location tags and Human Verification actions). Each request increments at most one of these counters. HTTP status charts stay separate.
If Human Verification allows a request and a later rate-limit stage blocks it, Analytics attributes the request to Rate Limit Block (not Firewall Allow).
Origin-generated 403/429 still appear under HTTP status traffic. They do not increment Firewall Block or Rate Limit Block unless Cloudo itself generated the response.
Authoritative Edge log fields include status, upstream response time, sec (location security tag), and hv (Human Verification action). Troubleshooting: compare client status → Edge JSON access log → collector batch → Analytics Security cards.
Click Blocked requests on the Dashboard (24h) or Analytics (Blocked card, Security block/challenge counters, or the Blocked chart legend) to open a detail drawer for the selected time range.
Detail rows come from Edge security events stored in PostgreSQL (not Redis). Cards and charts still use aggregate fw_block + rl_block counters so the main page stays fast; detail loads only when you open the drawer.
Aggregate card counts can be higher than detail rows when per-request events were not stored yet or have aged out of retention. The drawer shows both Aggregate blocked and Detail rows so you can see that gap.
Reasons are never invented. If an aggregate blocked count exists but no detail row is available (events from before security-event ingest, or aged out of retention), the drawer shows: Reason unavailable for this historical event.
Paths are normalized and query strings are not stored. Client IPs appear only on blocked-detail rows for investigation and are retained for a limited period (default 30 days). Unique Visitors still never stores visitor IPs — only HyperLogLog sketches.
Country breakdown uses the same approximate GeoIP as security. XX is Unknown and is labeled that way. It is not a country you can target with a firewall rule.
Cache HIT % is the share of HTTP requests served from Edge static cache. Origin % is the share that went to origin. HTML, POST, Authorization, and login-cookie requests count toward origin / bypass, not HIT.
Reset Cache or disabling CDN will drop HIT % until (or unless) static cache fills again.
An Edge node is Cloudo infrastructure that serves visitor HTTP/HTTPS. Authoritative DNS is served by dedicated DNS-capable nodes (`ns1` / `ns2`). An Edge is not your origin and not a customer server you SSH to from the Backoffice.
Staff see Edge Nodes globally. Domain owners work through domain pages; the Edge list is infrastructure.
Online means the Control Plane has received a heartbeat from the node within about 3 minutes. Offline means heartbeats stopped on a node that still serves HTTP or DNS. Retired or Disabled means the node is intentionally not a production HTTP/DNS plane (for example a lab leftover kept for history). Offline Control Plane connectivity is not automatically a visitor outage: the node can still serve its last valid local configuration.
Health is the last monitor evaluation and is only shown as current while the node is Online. When Offline or Retired, Health is Unknown so a stale snapshot is not mistaken for a live Healthy node. Nginx and CoreDNS badges appear only for nodes with HTTP or DNS capability.
You cannot manage new deploys to a node that cannot reach the Control API, but existing traffic can continue.
The Edge Nodes list defaults to Active: HTTP and DNS traffic-plane nodes that are not retired or disabled. The Dashboard Edge Nodes panel uses the same Active set.
Retired shows nodes kept for history (retired or disabled status, or mail-only leftovers without HTTP/DNS). All shows every registered node. Switching filters does not delete nodes, change DNS delegation, or change visitor traffic.
On Retired rows, Nginx/CoreDNS service badges stay blank when the node has no HTTP/DNS capability, and Sync is labeled Historical so an old successful deploy is not read as current.
Out of Sync means the version the Edge currently serves does not match the desired version in the Control Plane. Visitors still see the current local version, not the unapplied draft.
Queue or retry the matching HTTP/DNS/mail deploy. Do not delete the domain to “resync.”
HTTP deploys generate a candidate Nginx config, run nginx -t, and only then activate and reload. If nginx -t fails, the previous working config is kept and the deployment is reported failed. Operator alerts put the first fatal nginx [emerg] line (file and line) above deprecation warnings and keep the full validation output.
Normal deploys reload Nginx. They do not restart it. Restarting would drop connections and is not how configuration is published.
Backoffice Save & Deploy stores a Config Version and queues a job per Edge. The Edge writes a candidate, validates, activates atomically, reloads, and reports back. Visitor traffic changes only after a successful activation on that Edge.
HTTP, DNS, and mail are separate planes. Deploying DNS does not by itself update Nginx, and the reverse is also true.
Partial means some nodes succeeded and others failed. Retry still runs nginx -t (or DNS/mail validation) on the failed Edge. Never assume a failed node silently “took” the new config.
Re-queues a previous known-good Config Version to the Edge.
When a new version activated but behaves badly, or when you need to return to the last good snapshot.
Restores a previously validated snapshot if the rollback deploy itself validates.
Does not instantly rewind every resolver cache or every browser. Does not skip nginx -t.
If rollback validation fails, the currently serving configuration stays. Confirm which version each Edge reports before changing origins or DNS again.
Audit Logs record who did what, when, on which target, and with what result. Typical entries are domain, DNS, SSL, firewall, CDN, and deploy actions.
They are not traffic logs. They do not list visitor IPs or replace Analytics. Use them to see administrative history, not to debug a single HTTP 502.
Public resolvers still have the previous answer, or the registrar is not using Cloudo nameservers.
Registrar NS should be ns1.cloudo.lol and ns2.cloudo.lol. Compare several resolvers. Check TTL and last DNS deploy status.
Visitors using cached or old nameservers may hit the wrong place. Visitors using Cloudo NS see current published records.
Wait for TTL, confirm nameservers, and do not delete records to “force” propagation. Avoid lowering TTL repeatedly without deploying.
The browser, OS, or a local resolver cached the old A/AAAA. Sometimes HTTP/HTTPS connection reuse keeps the old path briefly.
Try another network or a public lookup. Confirm the Backoffice record and that DNS actually deployed. Flush local DNS only on your machine if you understand that it is local-only.
Usually only your session. Other visitors may already see the new address.
Do not remove the domain. Check DNS deploy succeeded, then wait out TTL.
ACME DNS-01 or certificate deploy has not finished. Status pending or issuing is expected for a while after Protection ON.
Nameservers on Cloudo, DNS deploy succeeded, _acme-challenge visible, SSL page error empty.
If a last valid certificate exists, HTTPS visitors may be fine. Brand-new domains may still be HTTP-only until active.
Wait for issuing to finish. Do not delete the domain. Retry only after nameservers and DNS deploys look correct.
DNS-01 could not complete, or the new certificate could not activate. The last valid certificate remains if one exists.
SSL error text, nameservers, _acme-challenge, and whether HTTP/SSL deploys failed validation.
Existing HTTPS often keeps working on the last valid cert. First-time issuance leaves HTTP until a cert is active.
Fix DNS/nameservers, retry issuance. Do not restart Nginx and do not wipe the last valid certificate to “start over.”
The Edge cannot get a valid response from the configured origin address, port, protocol, Host header, or SNI.
Origin process, origin firewall (allow Edge IPs), Origin page fields, and health monitoring (monitoring only).
Yes for HTTP(S) that must reach origin. DNS and cached static files (if CDN HIT) may still look alive.
Repair the origin. Do not change nameservers as the first step. Deploy origin edits after they are saved.
The Edge current version is behind the desired Config Version (Out of Sync), or a newer save was never deployed.
Deployments page: pending/deploying/failed vs succeeded. Edge current versus desired version.
Visitors see the last valid activated config, which may be older than the Backoffice form.
Retry the failed or missing deploy. Failed validation keeps the old config on purpose.
Candidate config failed validation or activation. For HTTP, nginx -t did not succeed. Previous config is still live.
The first fatal validation line (for HTTP, nginx [emerg] with file and line), the full validation output under any warnings, recent DNS/SSL/origin/firewall edits, and whether only some Edges failed (partial).
Visitors keep the last valid release on failed Edges. Succeeded Edges may already be on the new version.
Read the first fatal error, fix the snapshot, retry. Retry still runs nginx -t. Identical failures of the same desired version are not re-emailed on every retry. Do not restart Nginx to “make it take.”
Usually a firewall block matched the request (country, IP/CIDR, IP list, hostname, path, or method).
Security firewall rules, rule priority (lower first), IP Lists, and whether an allow should have matched first.
Yes for matching visitors. Others are unaffected.
Add a more specific allow or relax the block, then Save & Deploy. Avoid deleting all rules in a panic.
A rate-limit rule with Block was exceeded for that client IP on that Edge, or a platform connection/rate ceiling was hit.
Rate-limit threshold, interval, action, and whether many users share one NAT IP. Connection limiting is a baseline 64 concurrent per IP and has no UI editor.
Yes for IPs over the limit. Others are fine.
Raise the limit or switch Block to Challenge if appropriate, then deploy. Aggressive limits will 429 real users.
The Edge connected toward origin but got an invalid or immediate failure (origin down, wrong port/protocol, crashed app).
Origin address, port, protocol, Host header, SNI, origin process, and origin health monitoring.
Yes for uncached dynamic requests. Static CDN HIT may still succeed.
Fix origin first. Changing SSL or deleting DNS will not start the origin.
The Edge timed out waiting for origin. The origin is too slow, overloaded, or a firewall is dropping the connection.
Origin load, timeouts, firewall between Edge and origin, and whether only one origin in a pool is sick.
Yes for those requests. Other Edges or cached static files may still work.
Repair or scale the origin. Switching pool mode requires deploy and does not magically speed a dead primary.
Static css/js/image/font is still a cache HIT from before you updated the origin file.
CDN is On, X-Cache is HIT, and HTML is not the stale asset (HTML is not cached).
Visitors can see old static assets until Reset Cache deploys or the 7-day inactive expiry.
Use Reset Cache (confirms, bumps generation, queues HTTP deploy). It does not delete origin files and does not SSH.
That Edge missed heartbeats (~3 minutes). It may still be serving last valid local config, or it may be actually down.
Edge status, last heartbeat, whether the other Edge is online, and whether public DNS still lists both addresses.
Possibly for visitors who land on the down Edge. The other Edge can still serve. Control Plane offline ≠ this symptom.
Treat as infrastructure. Do not remove the domain. If the node is truly down, traffic to its IP fails until it recovers.
This is expected. Edges serve last valid local configuration without the Backoffice, API, or database on the visitor path.
Whether Backoffice loads, whether Edge heartbeats are stale, and whether deploys are stuck pending.
Usually no for already-deployed sites. New edits cannot publish until the Control Plane returns.
Do not rebuild domains. Wait for Control Plane recovery. Avoid making registrar NS changes unless DNS was never on Cloudo.
Drop deploys have not activated on every Edge, resolver TTL has not expired, or the registrar still points at Cloudo nameservers.
Domain status pending removal vs removed, DNS deployment status on each Edge, registrar NS, and TTL.
Yes — visitors may still hit Cloudo until drop deploys activate and caches expire. Removal can interrupt traffic.
Wait for queued drop deploys. Change registrar nameservers when you intend to leave Cloudo. Do not assume confirmation typing instantly clears the internet.
These Backoffice actions can interrupt visitor traffic or lock people out. They require deploy (and often typing the domain name). Edges keep last valid config until a new release actually activates — that is safety, not a reason to click twice.
Prefer: inspect current state, deploy once, wait for status, keep the previous working configuration when validation fails. Reload is the success path; restart is not.
