Architecture

ComponentsCopy Anchor Link

Console (ROLE=app|worker|all)
├── :3000  HTTP ◀── browsers, API clients
│          /node-channel (WebSocket, closed by default) ──▶ loopback connection to :8443
├── :8443  Connect-RPC (TLS + mTLS) ◀── edgeweir-node agent ── OpenResty ──▶ origins
│                                    ◀── edgeweir-node probe (regional probe) ──▶ node listeners
├── SQL, LISTEN/NOTIFY ──▶ PostgreSQL 18
├── HTTP (optional) ──▶ ClickHouse
└── child process stdin/stdout ──▶ edgeweir-certd ──▶ ACME CA, DNS provider APIs

The only contract between the console and the nodes is edgeweir.node.v1 in proto/ (current tag proto/v0.21.0). The boundary between the open core and commercial products is defined in LICENSING.en.md.

Repository layoutCopy Anchor Link

Processes and rolesCopy Anchor Link

ROLE selects what a process runs. All roles use the same image and the same database; deployment shapes and scaling: Deployment overview; all variables: Environment variables.

Startup sequenceCopy Anchor Link

1. Parse and validate the environment (lib/env.ts); on failure, list the invalid variables and exit.
2. Wait up to 60 seconds for PostgreSQL.
3. Apply pending migrations on a dedicated connection under an advisory lock; instances that start together run them one at a time.
4. Check that the internal CA key's envelope was sealed with EDGEWEIR_MASTER_KEY or EDGEWEIR_MASTER_KEY_PREVIOUS, or stop. Resolve the session secret (BETTER_AUTH_SECRET, or derived from the master key; after a master key rotation, the stored original) and compare it with the HMAC check value in the database: a derived secret that differs from the one the database was used with stops startup; a new explicit value is accepted with a warning (SECURITY.en.md).
5. Re-encrypt v1 envelopes written by older versions as v2; with EDGEWEIR_MASTER_KEY_PREVIOUS set, re-encrypt every envelope it sealed with the current master key and log how many still use it (services/envelope-rotation.ts).
6. Load the internal CA; generate it when the database has none.
7. app, all: before setup, create or read the setup token and write it to the log; start LISTEN; issue the node channel server certificate from the internal CA and start listening.
8. worker, all: start pg-boss, create the queues, register the schedules.
9. app, all: the HTTP server starts listening.

On SIGTERM or SIGINT the process stops the HTTP and node channel listeners, ends the nodes' config watch streams and stops pg-boss at the same time: requests in flight get up to 3 more seconds, pg-boss up to 5 seconds to finish running jobs; then the database pool is closed. If all of this takes more than 8 seconds the process exits with 1.

Ports and routesCopy Anchor Link

Reverse proxy and layer-4 passthrough configuration: Ports, reverse proxy, and trusted proxies.

HTTP routesCopy Anchor Link

Unmatched requests under /api, /rpc, and /downloads, and other methods on /install.sh and /healthz, return a 404 JSON body and never fall back to the SPA. Every response carries security headers; the CSP is default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self' data:; connect-src 'self'; frame-ancestors 'none'.

UI areasCopy Anchor Link

Authentication and authorizationCopy Anchor Link

Endpoints, the OpenAPI document, and AccessKey details: API and endpoints. The console has one operator account, with no organizations or roles: every procedure except system.status and system.setup goes through authed in rpc/base.ts (a valid session, an enabled AccessKey or a service account key).

The client IP (audit log, sign-in rate limiting) is the TCP peer; X-Forwarded-For and X-Real-IP are used only when the peer is in EDGEWEIR_TRUSTED_PROXIES (resolveClientIp). Rate-limit counters for the authentication endpoints live in the rate_limit table and are shared by all instances. Sign-ins and account changes completed by better-auth are audited by the hooks in lib/auth-audit.ts.

Account recovery has no HTTP entry and happens on the server only: dist/server/recover.js (services/recovery.ts) reads the console's environment and, in one transaction, resets the password (better-auth's password.hash), turns two-factor authentication off, deletes the account's sessions and pending two-factor sign-ins, and writes the audit entry account.recover (Command line).

Configuration publishingCopy Anchor Link

A change to node configuration runs in one transaction:

1. Write the application tables (sites, domains, origins, cache rules, rules, IP lists, L4 apps, certificates, ACME HTTP-01 responses, the origin allow list, the full-site purge generation).
2. publishRevision() takes an advisory lock on the cluster, reads the cluster's enabled sites and L4 apps, global rules, every IP list, the origin allow list, certificate references, and unexpired HTTP-01 responses, and compileNodeConfig() produces the canonical NodeConfig IR.
3. Compute content_hash: SHA-256 of the binary encoding with revision and content_hash cleared. Identical content produces no new revision.
4. The new revision number is one more than the larger of the latest stored revision and the highest verified applied revision reported by the cluster's nodes; restoring the database from a backup never moves revisions backwards.
5. Insert into config_revision, run pg_notify('edgeweir_config', …) in the same transaction, and write the audit entry.
6. After commit, every app instance receives the notification through LISTEN and pushes it to the WatchConfig streams of the cluster's nodes.
7. The node calls GetConfig(base_revision=applied revision), receives a diff or a snapshot plus a revision receipt, verifies the hash, stores it as last-known-good, applies it to OpenResty, and reports with ReportStatus.
8. The console records each node's applied revision and heartbeat in node_config_status; a node with a heartbeat in the last 45 seconds is online.

Revision reasons are codes (revision_reason_<code>) defined in packages/contract/src/errors.ts. Rule language: Rules.

Node tasksCopy Anchor Link

URL, prefix, host, Cache-Tag, and full-site purges and URL and sitemap prefetches produce no revision; they are delivered as typed tasks:

1. cacheTasks.create inserts a cache_task and a cache_task_node for every enabled node (disabled nodes are marked skipped), then runs pg_notify('edgeweir_tasks', …).
2. The WatchConfig stream emits WATCH_EVENT_TASKS.
3. The node pulls tasks with PullTasks and reports results with ReportTaskResult.
4. A task without a result 5 minutes after hand-out is handed out again; a task not finished within 7 days fails. When a node reconnects, the console issues a full-site purge for each site whose purges the node missed.

For a site with the PURGE method on, the node has its agent check the key of a PURGE request and hands it to the console with SubmitPurge; the console creates a URL purge task for the cluster as in step 1.

Host and Cache-Tag purges need the node feature purge-tag-v1, mobile and sitemap prefetches prefetch-v2; while an active node of an affected cluster lacks it, the console refuses the task (NODE_CAPABILITY_REQUIRED). Nodes derive cache keys from the purge markers' points in time and an index of the cached objects' Cache-Tag, so purged objects (stale ones included) are never looked up again; nodes fetch sitemaps through their own edge layer. Behavior: Origins and cache.

Node upgrades are delivered through PullTasks as well: an upgrade first runs on one node group and is promoted after the health observation passes; the remaining nodes follow at most a quarter at a time, and each task must finish within 30 minutes after it is sent. A node pulling tasks first checks without a lock whether it has an upgrade task, and takes the cluster's upgrade lock only if it does. Behavior: Node upgrades.

Dynamic bansCopy Anchor Link

IP bans (ip_ban) create no revision and skip the configuration canary; they have their own path over the node channel:

1. Every write (create, ban again, unban, automatic ban writes and overflow removal) takes nextval('ip_ban_seq') as the row's seq under one transaction-level advisory lock, so commits follow sequence order; the same transaction runs pg_notify('edgeweir_bans', …) with the affected clusters (all of them for platform bans). Manual actions are audited as ban.create, ban.update, ban.delete.
2. Nodes with bans-v1 receive WATCH_EVENT_BANS (ban_sequence is the sequence's current value) when their WatchConfig stream opens and after every notification.
3. The node calls GetBans(after_sequence): from 0, or from a sequence above the current value (after a database restore), it returns a snapshot (reset); otherwise the active bans and lifted ids changed afterwards. Expired bans are left out; nodes drop them at expiry. Reads take the same lock in shared mode first, so the current value never passes an uncommitted write. Pages hold 2000 entries by default and at most 5000; sequence is the page's highest sequence, or the current value on the last page.
4. Nodes upload their own automatic bans with ReportBans (at most 1000 per call), merged per node, site and address, and report the applied sequence, capacity and unapplied bans in ReportStatus.bans, kept in node.ban_status.

Behavior: Bans.

Challenges and CC mitigationCopy Anchor Link

Nodes enforce challenges, Under Attack and tiered CC mitigation locally; the console holds the settings, keys and events:

1. A site's protection (site_protection), global Under Attack (system setting protection_settings) and the CC template (cc_template) are compiled into NodeConfig. Only clusters that use challenges (global Under Attack, a site's Under Attack, an enabled CC policy or a challenge rule) carry challenge_keys, platform_protection and every site's protection, with challenge-v1 in required_features; a site that only records JA4 carries its protection alone. Rules that read tls.ja4 (or rate limit by it) and sites that record JA4 add ja4-v1. Other clusters keep their content hash.
2. Pass HMAC keys are per cluster, three of them (next, current, previous), created the first time a cluster uses challenges. The IR holds only key ids and roles (sorted by id); nodes fetch the 32-byte secrets with GetChallengeKeys, only those of their own cluster. A secret is generated the first time it is fetched and stored envelope-encrypted (purpose challenge_key.secret, bound to the row id).
3. maintenance.rotate-challenge-keys checks every hour and rotates keys once the newest one is a day old: previous is deleted, current becomes previous, next becomes current and a new next is created; clusters whose latest revision carries keys get a new revision (reason challenge_keys_rotated), audited as cluster.challenge_keys_rotate.
4. Nodes report level changes, escalated paths and automatic bans with ReportSecurityEvents (at most 500 per call); the console stores them in security_event, idempotent by (node, event id). A site leaving the normal level raises the cc_mitigation alert, at most once per site in 15 minutes. ReportStatus.security of the heartbeat is kept in node.security_state. maintenance.prune-security-events deletes events after the retention (default 30 days).

Behavior: Challenges and CC mitigation.

Compression and OWASP CRSCopy Anchor Link

Nodes compress and run CRS with OpenResty built for Edgeweir (edgeweir-openresty, optional module package edgeweir-openresty-modsecurity) and report brotli-v1, zstd-v1 and modsecurity-v1 according to their build. The console holds the settings, the capability gate and the match statistics:

1. A site's Brotli and Zstandard settings live with Gzip in site.tls_settings and are compiled into TlsOptions; only algorithms that are on carry their level, minimum length and types (types sorted and unique), so the content hash stays the same while they are off. Enabled sites with them on add brotli-v1 / zstd-v1 to required_features.
2. A site's CRS settings live in site_waf; unless the mode is off they compile into Site.waf (excluded rule ids ascending and unique) and add modsecurity-v1.
3. As with other capabilities, a service account or background publish that introduces a capability an active node of the cluster lacks gets NODE_CAPABILITY_REQUIRED; the operator may publish it. sites.features tells per site whether each feature can be turned on (reason nodes when not), and the UI disables the switches accordingly. Rollback recomputes the three capabilities from the sites it ships.
4. waf_rules of ReportStats (rule id → requests) keeps at most 50 rules per node, site and minute (nodes report only the 20 most-matched), rolls up into hours and days with the other per-minute statistics and is copied to ClickHouse minute_stats; waf.topRules sums a range. Access logs keep the matched rule ids (at most 16, ascending) and waf_blocked (PostgreSQL, ClickHouse, CSV). Rules with the log action likewise: MinuteStats.logged_rules (proto v0.18.0, node capability rule-log-v1; rule id → requests, UUIDs only) keeps at most 50 rules per node, site and minute (nodes report 20 as well) as logged_rules, with the same rollups and ClickHouse copy; rules.topLogged sums a range, joins the rules' current names (the site's own rules and global rules) and counts the active nodes of the site's cluster that lack rule-log-v1.

Behavior: HTTPS and certificates and OWASP CRS managed rules.

Rule engine extensionsCopy Anchor Link

The console is the only authority on expression syntax: packages/rule-engine parses conditions and value expressions and packages/config-compiler emits typed IR; nodes validate the IR field by field and run it, and never receive expression text. Functions, value expressions, bulk redirects, origin groups, cache rule conditions and the new rule actions are marked by the node capability rules-v2:

1. Function calls are encoded as call, field and const nodes of RuleExpression. Value expressions of redirect targets and rewrite paths go into RuleAction.target; set_query is sorted by name and remove_query sorted and unique; preserve_query is written only when it differs from the action's default.
2. Cache rules are stored as expressions (cache_rule.expression, with the lists they reference in list_ids). Expressions in the builder's shape compile into the former path_prefixes, paths and extensions, so older nodes run them as before and the content hash stays the same; other expressions compile into CacheRuleMatch.condition. browser_ttl_seconds goes into CacheRule.
3. Bulk redirects compile into Site.bulk_redirects (sorted by source) and origin groups into Origin.group.
4. A configuration that uses any of these (the compression phase and the new fields of config actions included) adds rules-v2 to required_features; others encode exactly as before. As with other capabilities, a change by a service account or background job that introduces rules-v2 while an active node of the cluster lacks it gets NODE_CAPABILITY_REQUIRED, while the operator may publish it; rulesV2 of sites.features lets the UI lock the controls.

The additions of proto v0.22.0 are marked by the capability rules-v3: cookies and query parameters by name (http.request.cookies.<name>, http.request.uri.args.<name>, the first raw value), new request and connection fields, http.response.cache_status, encoding and digest functions, substring (its integer arguments are const nodes of value_type number), to_string (an argument of any type), and the wildcard and strict_wildcard comparisons; request and response header values reuse RuleAction.target for their value expression, QueryParam.expression computes a query parameter, and RuleAction.append adds a response header line; redirect status 303; {{time}} and {{path}} in error pages. Nodes compute these fields only for sites whose rules read them; a computed header value over 4096 bytes or with a control character skips the action (one NOTICE per rule and node every 60 seconds, its message naming only the site and rule IDs), while a failed query parameter value still fails closed. Configurations that use none of them encode byte for byte as before (cross-language content hash vector content_hash_vector_v0220.json).

Proto v0.23.0 adds three capabilities. edge-ports-v1: a Listener may use a port besides 80 / 443 (the cluster's extra ports), Site.ports lists the listener ports a site is bound to (empty means every listener, the former semantics; a site on 80 / 443 in a cluster without extra ports compiles to empty), and TlsOptions.redirect_status / redirect_port / redirect_excluded_domains are the HTTPS redirect options; nodes render a site's server blocks on its ports only, and the router and the TLS callbacks treat its hosts on other ports as unknown. client-ip-v1: NodeConfig.client_address is the cluster's client address source; in the PROXY protocol mode every Listener.proxy_protocol is set, the trusted header mode reads the header with nginx realip (real_ip_recursive on); X-Forwarded-For towards the origins is the received chain plus the direct peer ($realip_remote_addr), the rule field ip.peer is the direct peer, and trusted CIDRs are never banned and not counted per address by CC. l4-v2: L4App.port_end (a port range, a stream listen range), L4Origin.port 0 for the arriving port, L4App.certificate_id / tls_minimum_version (stream ssl_client_hello_by_lua / ssl_certificate_by_lua check the SNI and terminate TLS; the certificate travels with the layer-4 table). Listener ports and the client address are the cluster's current state: a rollback keeps the current ones, and sites take their current ports and redirect options (refreshDerived(config, edge)). Cross-language content hash vector content_hash_vector_v0230.json.

Behavior: Rules, IP lists, and GeoIP and Origins and cache.

Layer-4 forwardingCopy Anchor Link

The nodes' stream subsystem forwards TCP / UDP L4 apps; the console handles ports, configuration, DNS, and statistics:

1. Port pools (cluster_port_pool) exist in the console only: an L4 app's port must fall inside a pool of its cluster for its protocol (1024–65535, no overlap within a protocol, never a port of the cluster's HTTP / HTTPS listeners). Writes to pools and apps are checked one at a time under an advisory lock of the cluster; changing pools publishes no revision.
2. L4 apps (l4_app, l4_origin) ship with the cluster's revision: enabled apps compile to NodeConfig.l4_apps (sorted by id, with the ids of the IP lists they reference) and add l4-v1 to required_features; disabled apps are not shipped. Origins follow the same origin address policy as sites.
3. Nodes render the port, protocol, whether PROXY protocol is accepted, and the version sent as a server in stream {} and reload, old workers serving open TCP connections until they end; origins, passive health check settings, timeouts, lists, and connection limits are hot-updated over the local control socket. Only apps that both accept and send PROXY protocol use a Lua relay; all others (v2 included) use native nginx forwarding.
4. DNS: compileBindingPlan writes a <app id>.<cluster domain> CNAME for every enabled app (with line aliases also <line>.<app id>.<cluster domain>), sharing the all-lines record, resolution lines, and backup node groups with sites.
5. Statistics: nodes report per app and minute connections, refused, peak_concurrent, bytes_received, and bytes_sent in ReportStatsV2Request.l4_stats, in the same batch as the sites' minute buckets and deduplicated by the same batch sequence; the console accepts only apps of the node's cluster and writes l4_minute_stats (no rollup, kept 7 days); l4Apps.stats buckets a range by 60, 300, or 3600 seconds.
6. Rollbacks and the canary's stable revision treat L4 apps by their current state: apps disabled now are not shipped; an app deleted since, whose port is no longer inside a pool, or that references a deleted list fails the operator's rollback (ROLLBACK_RESOURCE_UNAVAILABLE) and is left out of the stable revision.

Behavior: Layer-4 forwarding.

Node channelCopy Anchor Link

Connect-RPC over HTTPS; the console process terminates TLS itself.

Enrollment:

1. The operator generates an install command: a single-use token (valid for 5 minutes to 7 days, default 60 minutes, stored as SHA-256 only) and the SHA-256 fingerprint of the internal CA (--ca-sha256). The token travels in the EDGEWEIR_TOKEN environment variable.
2. The node checks the CA fingerprint in the server certificate chain, then sends the token and a locally generated CSR (Enroll).
3. The console verifies the CSR signature, issues the node certificate, and marks the token used and writes the audit entry in the same transaction.

Install command and install.sh checks: Adding nodes.

The console never stores SSH credentials; nodes join only through the one-time install command generated by the console and enroll themselves.

Every RPC other than Enroll and EnrollProbe requires a client certificate verified by the internal CA whose serial number equals the current serial stored for the node or probe: a rotated certificate stops working at once, and deleting a node or probe writes its serial to node_certificate_revocation. Disabled or deleted nodes are refused on every RPC, and their open WatchConfig streams close; a disabled probe may only renew its certificate.

A revision receipt is sealed with the master key (purpose node.revision_receipt, bound to the node ID) and carries the cluster, the revision, and the content hash. The node stores the receipt locally and returns it in ReportStatus; a report of an applied revision above the console's latest revision without a valid receipt is refused. During a master key rotation, receipts sealed with the old key stay valid.

Certificates and DNSCopy Anchor Link

edgeweir-certd performs ACME issuance, renewal, and revocation and DNS record operations.

1. The pg-boss queue certificates.sweep selects, every minute, certificates waiting for issuance and certificates past renew_at (new requests and manual renewals first, then by renew_at, three at a time). A failure backs off by the remaining validity (a tenth, 10 minutes to 12 hours; one hour for a first issuance); an HTTP-01 certificate that failed because names did not resolve to the nodes (http01_dns_not_pointing) has its names looked up again every 5 minutes and is retried once they point to the nodes. Issued certificates read their ARI renewal window after the CA's Retry-After (1 to 24 hours, 6 by default) and renew earlier when the window ends before renew_at.
2. The worker starts EDGEWEIR_CERTD_BIN (/usr/local/bin/edgeweir-certd in the image) with only PATH and EDGEWEIR_DNS_TEST_ENDPOINT in its environment.
3. It writes one JSON request line to stdin (command and parameters, including the ACME account and DNS credentials). certd writes JSON event lines to stdout (account, http01.present, http01.cleanup, dns01.prepare, dns01.cleanup); the console handles each one and acknowledges it on stdin. The last line is the result.
4. One http01.present carries all HTTP-01 challenges of an order: they are written to acme_challenge, each cluster involved publishes one revision, and once nodes apply it certd has the CA validate them (four at a time); http01.cleanup only deletes the rows and publishes nothing (nodes and the next revision drop a challenge once it expires or its operation ends). Challenge revisions do not count toward the 200 kept revisions and are deleted after an hour. dns01.prepare records the cleanup obligation in dns_challenge_lease before certd writes the TXT record; after completion, failure, or a restart, only the values written by that operation are removed. The ACME account from an account event is envelope-encrypted into acme_account; certificates with the same directory, EAB key id, and email share one account.
5. The result is written back to certificate: chain (certificates only), fingerprint, expiry, next renewal time, and the envelope-encrypted private key (PKCS #8); a request with bindSiteId (one-click HTTPS on a site's HTTPS tab, preceded by https.check, which lists every blocker at once: nodes, DNS, the DNS credential and CAA) is bound to the site in the same transaction (the HTTPS redirect and other settings unchanged); clusters that reference the certificate publish a new revision.

Domains a site's certificate does not cover yet (the certificate is being reissued for them) are published with Domain.tls_pending (proto v0.19.0) when every active node of the cluster has tls-pending-domains-v1, and nodes serve them over HTTP only; otherwise they are left out until the new certificate is issued.

Uploads and issued certificates with EC keys that spell out the curve's parameters are refused: nodes (Go crypto/tls) cannot load them. Uploads stored before are checked by maintenance.check-certificates at worker start, which opens their private keys: those nodes cannot load get status error with last_error certificate_chain_explicit_curve or certificate_key_explicit_curve, audited as certificate.unloadable. Saving a site's HTTPS settings checks the chosen certificate itself and refuses such a certificate with CERTIFICATE_CHAIN_EXPLICIT_CURVE / CERTIFICATE_KEY_EXPLICIT_CURVE; a site bound to one is not changed automatically, and its cluster's nodes apply a new revision once another certificate (or none) is bound.

DNS steering is bound per cluster (dns_binding, mode Not managed, Manual, or Automatic): dns.reconcile computes, every minute, the records of each cluster in Automatic mode from healthy nodes and site domains (one set of address records per cluster, all.<domain> once per resolution line, one CNAME per site; node addresses and backup node groups as in Regional probes and scheduling), creates a dns_revision for that cluster, and writes it to the zone of the binding's provider account (platform_dns_provider); clusters publish and reconcile on their own, so an unavailable provider does not affect other clusters, and one process at a time writes a cluster (dns_lease). Nodes keep their records while they apply a revision published less than 2 minutes ago. Names are recorded in dns_managed_name before external records are written, so partial writes can be repaired; new records are written before the records they replace. Manual mode only produces the records to create and a zone file and writes no DNS. DNS steering provider accounts and DNS-01 credentials use the same provider catalog. A site's domains route as soon as they are saved; a domain belongs to one site. Behavior: HTTPS and certificates, DNS steering and alerts.

Regional probes and schedulingCopy Anchor Link

1. Probers: regional probes (probe; edgeweir-node probe enrolls through EnrollProbe with a one-time probe_token), or nodes with node.probe_enabled whose node group has a region (probe=true in the ReportStatus response).
2. GetProbeTargets returns every enabled node's scheduling addresses (node_ip: only the configured rows and their levels when there are any, otherwise the public reported addresses) × the listener ports of the cluster's latest revision, with interval, timeout, and attempts; HTTP / HTTPS listeners are probed through the health endpoint when every active node of the cluster has probe-health-v1, otherwise with TCP only. A node that also probes skips itself.
3. ReportProbeResults accepts current targets only and writes probe_result (one row per prober, node, address, and port, latest value); rows not updated for 1 hour are deleted.
4. Every 10 seconds (an in-process timer of the worker; a lease lets one process run at a time) and after every probe report (at most every 2 seconds per cluster and process), each cluster is evaluated in a transaction (advisory lock): first node_address_state from the results in the window (3 intervals, at least 15 seconds; a strict majority of probers failing for ipDownSeconds makes an address unreachable, ipUpSeconds without failing makes it reachable), then scheduling_state for every scheduling_rule and node (since when each condition holds, the action started, the conditions cleared).
5. An address level change publishes the cluster's DNS revision (reason health). Every activation and recovery of a rule publishes one (reason scheduling, reason_params with rule, node, action, and event), is audited with the system identity as scheduling.activate / scheduling.recover, and raises or resolves the platform alert scheduling_action. Clusters with a new revision are written to DNS right away.
6. compileBindingPlan computes each binding line's addresses from the nodes' effective levels (the lowest reachable level, at least backup 1 under a backup_ip action), rule removals, and the line's backup node groups (fewer healthy addresses than minHealthyIps, or a backup_group action); all.<domain> is written per resolution line. The mass removal protection compares per name, type, and resolution line, and counts backup group switches only when they empty a record set.

Node metrics (ReportStatusRequest.metrics, metrics-v1) are kept in node.metrics, latest value only; scheduling treats metrics older than 60 seconds as missing.

Behavior: Regional probes and scheduling.

Statistics, logs, and alertsCopy Anchor Link

Access logs are sampled per site; the sample rate defaults to 0 (off). Per-minute statistics pre-aggregated by nodes go to node_minute_stats; the worker rolls them up into node_hour_stats and node_day_stats, and the view traffic_hour_stats combines rolled-up and pending data. Overview, site statistics, and the platform overview query 1-hour, 6-hour, 24-hour, 7-day, and 30-day ranges in buckets (date_bin); the 7-day and 30-day ranges read hourly data.

Alerts (alerts.sweep, every minute) detect offline nodes, expiring certificates, unavailable origins, and high 5xx rates (the cc_mitigation alert fires on a node's event and resolves once no node reports the site above normal), create alert_event rows, fan them out to alert_delivery by alert_subscription (one per channel, covering a set of sites in alert_subscription_site or all sites with all_sites), and send them through an alert_channel (webhook, email, DingTalk, WeCom, or Telegram); at delivery the channel must still be enabled and the subscription still valid, and "receive every alert" channels get every alert. Cluster alerts (configuration canary rolled back, DNS mass removal blocked, a scheduling rule acting on a node scheduling_action, and others) are raised and resolved by their own flows and go only to "receive every alert" channels. Access logs and AccessKeys: Access logs and AccessKeys.

Background jobsCopy Anchor Link

Data modelCopy Anchor Link

Tables are defined in packages/db/src/schema; migrations are plain SQL generated by drizzle-kit in packages/db/migrations and run at console startup (see Startup sequence).

Account and identitiesCopy Anchor Link

InfrastructureCopy Anchor Link

Sites and configurationCopy Anchor Link

Certificates, DNS, and domainsCopy Anchor Link

Statistics, logs, tasks, and alertsCopy Anchor Link

The view traffic_hour_stats combines hourly rollups with minute data not rolled up yet, without double counting.

MigrationsCopy Anchor Link

Build outputCopy Anchor Link

Base images are pinned by tag and multi-arch index digest. The image version is <YYYYMMDD>-<commit> (scripts/image-version.sh), written to EDGEWEIR_VERSION and the image label org.opencontainers.image.version; the full commit ID goes to org.opencontainers.image.revision. Development commands and tests: CONTRIBUTING.en.md.

ObservabilityCopy Anchor Link