Cloud vs Self-Hosted
Relevant source files
The following files were used as context for generating this wiki page:
Send Again provides two primary deployment models: a managed Cloud version and an open-source Self-Hosted version. While both versions share the core feature set—including the REST API, AI email composition, and campaign analytics—they differ significantly in infrastructure management, email delivery configuration, and billing structures.
The Cloud version, accessible at send-again.com, is designed for immediate use with zero infrastructure overhead. In contrast, the Self-Hosted version allows developers and organizations to maintain full control over their data and infrastructure by deploying the application within their own AWS and Supabase environments.
Sources: README.md:1-12, README.md:21-28
Feature Comparison
The primary differences between the two versions center on who manages the underlying resources and how updates are applied.
| Feature | Cloud (send-again.com) | Self-Hosted |
|---|---|---|
| Setup Overhead | None - Sign up and go | Requires infrastructure management |
| Email Delivery (SES) | Managed by Send Again | Requires your own AWS account |
| Billing/Limits | Credit-based (1,000 free, then packs) | No limits (unless configured) |
| Software Updates | Automatic | Manual (Pull from GitHub) |
| Infrastructure | Managed (Supabase/Hosting) | Self-managed (Node.js/Supabase) |
Sources: README.md:21-28
Self-Hosted Architecture
A self-hosted instance requires several external dependencies and environment configurations to function correctly. The application is built on Node.js and relies on Supabase for authentication and database services.
Infrastructure Components
- Node.js 20+: The runtime environment for the application.
- Supabase Project: Provides the PostgreSQL database and Authentication services.
- AWS SES: Used for email delivery; requires a verified domain and SNS configuration for event tracking.
Sources: README.md:30-35, README.md:109-114
Deployment Logic
The following diagram illustrates the relationship between a self-hosted instance and the required service providers.
This diagram shows the data flow between a self-hosted instance and the external cloud providers required for full functionality.
Sources: README.md:30-41, README.md:109-114
Billing and Credit Management
The Cloud version implements a credit-based billing system powered by Polar. Credits are consumed on a per-recipient basis.
Cloud Billing Logic
- Free Tier: New workspaces receive an initial allocation of 1,000 free credits.
- Credit Packs: Users can purchase top-up packs via Polar checkout.
- Enforcement: Billing can be enforced via environment variables (
BILLING_ENFORCED=true), which triggers checks during the email sending process.
Sources: README.md:92-106, src/app/app/page.tsx:327-371
Billing Configuration Parameters
In a self-hosted environment, these parameters can be customized to either disable billing or implement a private credit system.
| Variable | Default | Description |
|---|---|---|
BILLING_ENFORCED | false | Enables/Disables credit checks on send |
FREE_TIER_INITIAL_CREDITS | 1000 | Credits granted on workspace creation |
POLAR_SERVER | sandbox | Polar environment (sandbox or production) |
POLAR_CREDIT_PACKS_JSON | — | JSON array defining available top-up packs |
Sources: README.md:92-106
Email Deliverability and DNS Automation
Both versions support automated DNS configuration for SPF, DKIM, and DMARC. This is critical for maintaining high deliverability across both managed and self-hosted environments.
DNS Setup Flow
The application provides integrated setup for Namecheap, Cloudflare, and Route 53. The process involves verifying the domain in SES and then programmatically injecting the required records into the DNS provider.
The sequence of operations for automating email deliverability records.
Sources: src/app/api/workspaces/setup/route.ts:169-231, src/app/app/page.tsx:1438-1481
Supported Setup Actions
The /api/workspaces/setup endpoint handles the following deliverability tasks:
verify-domain: Initiates SES domain identity verification.setup-dkim: Generates DKIM tokens for CNAME records.create-config-set: Creates an SES Configuration Set for tracking.configure-namecheap-dns/configure-cloudflare-dns/configure-route53-dns: Automates the actual record injection.
Sources: src/app/api/workspaces/setup/route.ts:169-210
Security and Authentication
The authentication mechanism remains consistent across both models, but the source of the credentials differs.
Authentication Methods
- Supabase JWT: Standard bearer token used for dashboard access and browser sessions.
- API Keys: Scoped keys (e.g.,
contacts.read,send.write) used for programmatic access. - Self-Hosted Override: Administrators can define
INITIAL_OWNER_EMAILandALLOWED_AUTH_EMAILSto restrict who can sign up for their private instance.
Sources: README.md:118-121, src/lib/openapi.ts:13-25, README.md:58-60
Conclusion
The choice between Cloud and Self-Hosted deployment depends on the user's requirements for management ease versus infrastructure control. The Cloud version offers a "zero-setup" experience with managed SES and billing, while the Self-Hosted version provides a robust, private infrastructure for organizations that already utilize AWS and Supabase and require direct control over their sending limits and data retention.
Sources: README.md:21-28, src/app/privacy-policy/page.tsx:12-25