How BRICQS actually works

Provision a real, dedicated managed SQL database server — not a shared multi-tenant cluster. Each database gets its own server, its own table editor (browse/filter/insert/delete rows), a real SQL editor with saved/private/shared queries, a compute-tier picker backed by real dedicated hardware tiers, and a connection-string reveal that is logged every time it is viewed. Connect a GitHub repository to a database and pushes to your configured production branch auto-apply any pending SQL migrations — scoped to that one branch, so a push to a feature branch never touches your live data.

vector search is available on every provisioned database — no extension install required. This is the same vector store backing the RAG runtime.

Every GPU Runtime deployment can run in development, preview, or production — a project can hold all three simultaneously, each as its own real, separately billed BRICQS Compute instance. The app names use deterministic suffixes (-dev, -preview, no suffix for production) to avoid platform name length limits.

Promoting a preview to production provisions a fresh production container from the preview's exact configuration and only retires the prior production deployment once the new one is confirmed running — never a stop-then-create gap. If the retire call fails, a background retry thread attempts with exponential backoff (4 attempts, 30/60/120/240 second delays) rather than leaving a manual fallback instruction.

A live deploy pipeline shows real stage transitions: queued → connecting → creating container → provisioned → waiting for model → running. Each transition is tracked in the stage column and surfaced in the console's pipeline panel, polled every ~2 seconds.

BRICQS includes a full domain platform — not a CNAME-point-and-pray CDN integration. Domains are a first-class resource, decoupled from any single deployment. You can add a domain you already own or purchase a new one, then independently attach it to a GPU Runtime deployment, a workflow deployment, or leave it unattached and manage DNS from the console.

Every domain transitions through a real state machine: unattached → verifying → verified → ssl_pending → active (or failed). Each transition is driven by a real DNS check, cert issuance result, or Container App binding result — not a simulated status. WebSocket live updates push each job progress to the console without polling.

Search availability across TLDs, compare prices, and purchase domains backed by BRICQS Registrar. Registrant profiles can be saved and reused. Domain transfers (in and out) are supported with real EPP auth code flow and status polling. WHOIS privacy toggle is available per domain.

Add, update, and delete A/AAAA/CNAME/MX/TXT/NS records. Import existing records from the live zone. Apply pre-built DNS templates (common setups for email providers, CDNs, etc.). Take DNS snapshots at any point and restore them with a single API call. An AI DNS assist endpoint suggests records based on your deployment context.

BRICQS SSL certificates are issued via DNS-01 challenge (no public HTTP endpoint required), with wildcard support (*.yourdomain.com). BRICQS writes the required _acme-challenge TXT record automatically when the domain's DNS is managed by BRICQS, waits for real propagation, then issues and binds the cert to the Container App. Cert transparency logs are visible per domain. Certificate revocation is supported.

Define custom edge routing rules per domain, served by the BRICQS edge router. Create URL redirects with any HTTP status code (301, 302, 307, 308) — BRICQS provisions a real Container App redirect app rather than a DNS-only approach. Enable a maintenance mode page that gates all traffic with a custom HTML/CSS page while the domain stays live.

Per-domain security checks cover: CAA records (restrict who can issue certs), DNSSEC status, HSTS header (auto-set for tenant domains routed through the edge router), cert transparency log presence, and email health (MX, SPF, DKIM, DMARC). A domain risk report aggregates findings across your entire portfolio.

Wildcard-eligible domains can have subdomains onboarded as tenant routes — each subdomain maps to a target deployment via the edge router. This powers multi-tenant SaaS setups where each customer gets a dedicated subdomain (e.g. customer.yourdomain.com) without a separate Container App per tenant.

Every custom domain on BRICQS is served through a real edge router — a dedicated BRICQS Compute instance (BRICQS Edge Router) that is the actual traffic path, not a CDN integration. The edge router emits one JSON log line per request to stdout, which BRICQS Compute automatically indexes into BRICQS Monitor.

9 OWASP managed ruleset categories are applied to every request: SQL injection, XSS, remote file inclusion, path traversal, PHP injection, Apache injection, IIS injection, cross-site scripting, and scanner detection. Rules are evaluated in priority order; the first match blocks the request and logs it with the matching rule name.

Multi-signal bot scoring combines: per-IP request rate (5-second and 60-second windows), suspicious path patterns (crawlers, scanners, .env, wp-admin), user-agent fingerprint matching against known bot signatures, and IP reputation list lookup. A request exceeding the score threshold is blocked with a 403 and logged as blocked: true.

All 5 RIR delegation files (ARIN, RIPE, APNIC, LACNIC, AFRINIC) are downloaded and compiled into a binary-packed in-memory table of 259,824 IPv4 ranges (~2.5 MB). Each request is tagged with the originating country code, available in the country field of the log line and surfaced in edge analytics as top-5 countries.

Cacheable GET responses are stored in BRICQS Cache. The edge router authenticates using BRICQS Identity exclusively — Redis runs with key-based auth permanently disabled (zero-credential mode), meaning access keys are permanently disabled at the infrastructure level. A short-lived BRICQS Identity bearer token is acquired via BRICQS identity credential, the oid claim is decoded from the JWT payload (no metadata call required), and the token is refreshed every 40 minutes. Cache hits are logged with rule: "cache-hit" and the real cache hit ratio is computed in BRICQS Monitor from BRICQS Monitor.

The API server exposes a cache purge proxy endpoint. The purge token is stored as an encrypted Container App secret (not a plaintext env var) and is never exposed to API callers — the server holds it and proxies the purge request to the edge router.

BRICQS enforces a zero-credential posture for all infrastructure-to-infrastructure communication:

• Zero-credential cache auth: The edge router holds a system-assigned managed identity. It acquires a short-lived identity token scoped to the cache service scope, decodes the oid claim from the JWT payload, and authenticates to Redis using identity token credentials. No metadata call required. Token auto-refreshes every 40 minutes.
• zero-credential mode: Redis is configured with key-based auth permanently disabled at the platform level. Access keys do not exist and cannot be re-enabled without an platform resource update.
• Encrypted secrets: Sensitive values (purge tokens, service credentials) are stored via BRICQS secret store (encrypted at rest by BRICQS) and surfaced to services as named secret references, never as plaintext environment variables.
• Org-level secrets vault: Every organization has its own dedicated secrets vault. Provider API keys are stored there — the application database holds only a reference, never the real value.
• Redis access policy: The managed identity is bound to the Data Owner access policy on the Redis resource via BRICQS Identity policy binding.

Every push to the main branch runs a fully automated pipeline with no manual steps:

1. Security scan: Trivy filesystem scan for secrets and HIGH/CRITICAL CVEs (exit-code 1 on finding), pip-audit --strict, npm audit --audit-level=high.
2. Build and push: Docker build + push for api, web, and edge-router images. Each image gets an additional Trivy per-image CVE scan before the stage completes.
3. Apply migrations: migrate.sh runs every pending SQL file against the live managed SQL database instance. Applied migrations are tracked in a schema_migrations table — idempotent, no file is applied twice.
4. Approval gate: A manual approval step gates production deployment.
5. Deploy: BRICQS Compute updated with the new image tags.
6. Smoke test: Basic health checks after deploy. East region smoke test runs only when the East region environment is provisioned.

BRICQS Compute automatically collects platform telemetry for every deployed app with no application-side instrumentation required. BRICQS exposes this via the BRICQS Monitor SDK BRICQS Monitor metrics API API:

• CpuPercentage, MemoryPercentage — real platform resource utilization
• Requests, ResponseTime — request count and response time (ms) from the BRICQS ingress
• Replicas — real replica count over time
• GpuUtilizationPercentage — for GPU catalog models (gracefully empty if no GPU workload data in window)

The GET /deployments/{id}/metrics?hours=6 endpoint returns a 5-minute-interval series for each metric. The deployment detail view renders these as inline line charts (hand-rolled SVG, no chart library dependency). For deployments with no traffic in the window, the response is an empty series — not a fabricated zero.

Distributed traces (per-request span data) are not yet available. Platform metrics give time-series aggregates — individual request traces require per-request tracing instrumentation inside the served model container, which does not exist yet. This is the one remaining honestly-deferred observability item.

curl https://api.bricqs.cloud/runtime/{project_id}/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

from openai import OpenAI

client = OpenAI(
    base_url="https://api.bricqs.cloud/runtime/{project_id}",
    api_key="not-needed-for-session-auth",
)
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Hello!"}],
)
print(response.choices[0].message.content)