Security | Blog Monkee

Security

Last updated: [DATE]

Blog Monkee stores your WordPress credentials, WP Engine API keys, and the content you generate. We treat that responsibility seriously. This page documents our security posture — in the same honest tone we use everywhere else on this site.

Infrastructure

  • Hosting: Render.com (US region: [oregon / us-east]). Render runs on AWS and Google Cloud underneath, providing infrastructure-level DDoS protection and regional redundancy.
  • Database: PostgreSQL 16 hosted on Render, automatic daily backups, 7-day point-in-time recovery.
  • Cache / queues: Redis hosted on Render with persistence enabled (allkeys-lru eviction policy).
  • Static storage: Amazon S3 with versioning enabled on content-generation artifact buckets.

Encryption

  • In transit: TLS 1.2+ enforced on all endpoints. HSTS enabled on all public domains.
  • At rest: PostgreSQL disk encryption (AES-256). S3 server-side encryption (AES-256). Integration credentials stored in additional encrypted columns using application-level encryption.
  • Passwords: bcrypt with cost factor 10. We never store or transmit plaintext passwords.

Authentication

  • User auth: JWT tokens with 24-hour expiry, stored in localStorage with a single session cookie.
  • API authentication: every backend endpoint (except public health/RSS/signup) requires Authorization: Bearer <JWT>. 401 responses trigger automatic client logout.
  • Admin access: internal admin endpoints require a separate HEALER_API_KEY shared secret, scoped to monitoring cron and explicit admin operations only.
  • SuperAdmin role: production dashboard reserves SuperAdmin-gated routes; access requires both role assignment AND a rotating unlock code.

Secrets management

  • No secrets in source code, commit history, or configuration files tracked in Git.
  • All API keys, database URLs, and third-party credentials are injected via Render’s environment variable system at runtime.
  • Credential rotation: quarterly for AI provider keys; immediate on any suspected compromise.

Application security practices

  • Dependency scanning: automated via GitLab’s built-in scanners on every commit.
  • Regex safety: all content-cleaning regexes bounded with explicit quantifiers (e.g. {0,5}) to prevent catastrophic backtracking.
  • Credential leak prevention: WordPress Multisite credential-in-URL auth retry paths redact //user:pass@ patterns from error logs before they ship to Render’s log aggregation.
  • AI output validation: every JSON response from Gemini/OpenAI is schema-validated before use.
  • Rate limiting: per-user rate limits on all AI-generation endpoints prevent runaway cost and abuse.
  • CORS: explicit origin allowlist, no wildcard origins.

Self-healing monitoring

Blog Monkee runs a dedicated “Self-Healer” cron service every 15 minutes that checks signal health (Redis reachability, database connectivity, queue depth, stuck campaigns, Render service status). Known incident patterns are handled automatically via runbooks. Unknown incidents escalate to a Claude AI agent for triage, with all actions logged. Hard failures email the operator on duty at help@oneclickseo.com.

Incident response

  • Detection: self-healer + Render uptime monitoring + external Better Uptime monitoring.
  • Containment: documented runbooks for the 10 most common failure modes.
  • Notification: if user data is materially affected, we notify you within 72 hours by email.
  • Post-mortem: every hard incident produces an AI-drafted post-mortem, reviewed by a human before closure.

What we don’t claim

Blog Monkee is not yet SOC 2 certified. We are not HIPAA-compliant. We are not FedRAMP-authorized. If you need any of those attestations, Network plans can be architected on dedicated infrastructure — contact sales@monkee.ai.

Responsible disclosure

If you find a security vulnerability, please email security@monkee.ai. Please do not publicly disclose until we’ve had 90 days to investigate and remediate.

Contact

Security inquiries: security@monkee.ai
Data requests: privacy@monkee.ai