Production Checklist

Going to production means your application is serving real users with real data. MemorySync is designed for production use from day one, but there are configuration and security steps that must be completed before you expose the API to live traffic.

This checklist covers the seven areas most likely to cause issues: API key hygiene, webhook security, rate limiting, audit retention, health verification, environment configuration, and middleware ordering. Complete every item — skipping even one can lead to data leaks, quota exhaustion, or silent failures.

API keys are the primary authentication mechanism for the memory API. Before go-live:

• Rotate development keys. Any API key used during development or staging should be revoked. Generate fresh production keys through the dashboard.
• Scope keys to projects. Each API key is scoped to a specific project via the X-Project-ID header. Never share a single key across multiple projects.
• Store keys in secrets. API keys must live in your secrets manager or environment variables — never in source code, config files, or client-side bundles.
• Enable usage tracking. MemorySync automatically records per-key usage metrics (request count, last used timestamp). Verify these metrics appear in your dashboard after the first production request.

If you use webhooks to receive event notifications, verify these security settings:

• HTTPS endpoints only. The webhook delivery worker rejects HTTP endpoints in production. All webhook URLs must use TLS.
• Signature verification. Every webhook delivery includes an HMAC-SHA256 signature in the headers. Your receiver must verify this signature against your webhook secret to prevent spoofed deliveries.
• Retry behavior. Failed deliveries are retried with exponential backoff. After exhausting retries, events are moved to a dead-letter queue. Monitor the dead-letter count to detect endpoint failures.
• Delivery worker health. Webhook deliveries are dispatched asynchronously in the background. They start automatically on boot and drain in-flight deliveries on graceful shutdown.

Rate limiting runs as middleware — it returns 429 responses before any business logic executes:

MemorySync records every API call in the audit log for compliance. Before go-live, configure the retention policy:

• Default retention. Audit logs are retained for 90 days by default. Enterprise plans can extend this.
• Automatic enforcement. The platform purges expired audit entries automatically once they pass the retention window — no operational action is required from your team.
• Tombstone records. Deleted data leaves tombstone markers for 90 days to prevent resurrection from any backup. Tombstones are cleaned up automatically once they expire.
• Compliance requirements. If your organization is subject to GDPR, CCPA, or SOC 2, verify that your retention period meets regulatory requirements. Some frameworks require longer retention.

MemorySync exposes a GET /health endpoint that checks the status of all critical platform dependencies. Before go-live, confirm the response returns "status": "ok":

• Overall status. The endpoint returns ok when all internal services are reachable and operational, or degraded when one or more services are unavailable.
• No authentication required. The health endpoint is publicly accessible and rate-limited to 5 requests/second per IP — ideal for load balancer health checks and container orchestrator readiness probes.
• What to do when degraded. A degraded response means some features (e.g., semantic recall or caching) may be temporarily unavailable. Core API operations may still work. Check the MemorySync status page for ongoing incidents.

Point your load balancer or container orchestrator at GET /health for liveness and readiness probes.

MemorySync is a fully managed cloud platform — you do not need to provision databases, configure encryption, or manage infrastructure. Before routing production traffic, verify these steps in your dashboard: