SendPortal: Self-Hosted Email Marketing and Campaign Management

Why SendPortal Exists as a Stand-Alone Application

SendPortal addresses organizations that want to operate an email marketing system without treating newsletter delivery as part of an unrelated business application. It brings subscriber and list management, email campaigns, message tracking, reports, and support for multiple workspaces and domains into one self-hosted PHP application. The intended operator is therefore not only a developer looking for a campaign library, but also an organization that wants its own installation and user authentication.

The repository distinguishes two forms of use. The full SendPortal application acts as a wrapper around the SendPortal Core package and includes authentication plus workspace management. SendPortal Core contains the core functionality. An application that already handles user authentication is directed to install only SendPortal Core rather than adopting the complete stand-alone application.

That distinction matters because the full application is not merely a rendering layer for an external mailing system. Its documented scope includes the operational parts required to run newsletters as a service. However, the README does not describe tenant isolation details, permission granularity, unsubscribe handling, or the operational process for deleting a workspace. Those points require review of the linked documentation and the relevant repository files before an organization relies on them for compliance-sensitive subscriber data.

SendPortal Core and the PHP Application Boundary

The visible integration model has two layers. SendPortal Core holds subscriber, list, campaign, tracking, and reporting behavior. The SendPortal repository supplies the stand-alone application around that package, with routes, configuration, application code, database resources, authentication, and workspace support represented in the repository layout. This gives developers a clear choice between embedding the campaign system and operating the complete product.

The choice is based on application ownership. If another application already owns authentication, the README says that only SendPortal Core is required. If the goal is to run a separate copy with its own user authentication and multiple workspaces, this repository is the relevant choice. The documentation does not provide a code example showing how an existing application initializes SendPortal Core, nor does it enumerate the core package version used by V4. The package installation guide is therefore the authoritative next document for an integration project.

Delivery remains provider-facing rather than tied to one mail server. The README names Amazon SES, Postmark, Sendgrid, Mailgun, and Mailjet as integrations. It does not document whether every listed provider supports every feature in the application, nor does it state how provider selection, credentials, or delivery events are configured. Those provider-specific checks should happen before migration, since they can affect which providers are viable alternatives.

SendPortal V4 Requirements and Configuration Surface

SendPortal V4 sets explicit platform requirements: PHP 8.3 or later, Laravel 13, and either MySQL 5.7 or later or PostgreSQL 10 or later. This is a substantial version boundary. Applications running PHP 8.2 or Laravel 10 or 11 are directed to SendPortal V3, while earlier PHP 7.3-era or Laravel 8-era deployments are directed to SendPortal V2.

The repository includes an `.env.example` file with application, database, cache, queue, session, mail, AWS, Redis, Pusher, and SendPortal settings. The following excerpt shows the documented defaults without implying that copying it alone completes installation:

APP_NAME=SendPortal
APP_ENV=local
APP_URL=http://localhost
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=sendportal_dev
DB_USERNAME=homestead
DB_PASSWORD=secret
CACHE_DRIVER=file
QUEUE_CONNECTION=sync
SESSION_DRIVER=file

This default selects MySQL, local file caching, synchronous queue processing, and file-based sessions. Redis and Mailtrap values also appear in the example, as do Amazon AWS credentials, but the README does not explain whether Redis or a particular mail transport is required by SendPortal itself. A first deployment should not be built on assumptions about those entries. The configuration shown here establishes the variables exposed by the repository, while the official installation guide remains necessary for the complete setup sequence.

Installing SendPortal and Reaching the First Campaign

The README directs stand-alone users to the version-specific installation guide at `https://sendportal.io/docs/v4/getting-started/installation`. It does not reproduce the installation commands, web-server requirements, key-generation step, migration command, or process-manager instructions. Because the README does not provide those commands, inventing a `composer install` or `artisan` sequence would be misleading.

The first usable milestone, according to the documented feature set, is a SendPortal installation where an authenticated operator can manage subscribers and lists, create an email campaign, select a supported delivery integration, and use message tracking and reports. The exact menu path and required fields are not documented in the README. The installation guide is therefore the first place to verify how database setup, application keys, mail-provider credentials, and the web server are configured.

For an existing Laravel application, the workflow is different. The README sends that reader to the package installation guide at `https://sendportal.io/docs/v4/getting-started/package-installation`. The first check there should be whether the existing application can supply the authentication and user context that SendPortal Core expects. Without the guide contents, the repository evidence supports the package distinction but not a claim that integration requires only dependency installation.

Operational Limits of SendPortal V4

SendPortal's self-hosted model places more responsibility on the operator than a hosted newsletter product would. The application requires its own PHP runtime, Laravel 13 environment, database, and deployment maintenance. The supported database floor is MySQL 5.7 or PostgreSQL 10, while the application runtime floor is PHP 8.3. A deployment built around PHP 8.2 or Laravel 10 or 11 cannot use V4 according to the README; it must use the older V3 line.

The example configuration uses `QUEUE_CONNECTION=sync`, but the README does not say whether campaign delivery is always queued, whether production requires a different queue driver, or how failed jobs are retried. It also does not document rate-limit behavior beyond the exposed `SENDPORTAL_THROTTLE_MIDDLEWARE=60,1` setting. The meaning of that setting and its interaction with campaign sending are not confirmed in the repository documentation.

Another limitation is the absence of documented delivery semantics. Provider integrations are named, but bounce handling, complaint handling, suppression lists, message retries, and webhook configuration are not described. SendPortal should not be treated as a complete substitute for a provider's deliverability operations until those behaviors are verified. The self-hosted label concerns where the application runs, not whether the sending infrastructure is operated locally.

Maintenance, Releases, and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-10-12. A release named `v4.0.0` is dated 2026-10-12, while the listed `v3.0.1` and `v3.0.0` releases are dated 2024-04-19. This indicates a recent V4 release in the repository history, but the README does not provide upgrade compatibility guarantees or a detailed changelog summary.

Upgrades from V3 have a separate guide at `https://sendportal.io/docs/v4/getting-started/upgrade-guide`. That separation is consistent with the major runtime changes: V4 moves the stated baseline to PHP 8.3 and Laravel 13. An upgrade review should therefore include the application framework, PHP runtime, database version, environment configuration, provider credentials, and any existing customizations. The README does not state whether database migrations are reversible, so rollback should not be assumed.

SendPortal is released under the MIT license. That license is the repository's stated licensing information and permits use under its terms, subject to the actual license text. This review does not interpret the license or provide legal advice. Third-party delivery services, hosting, domains, and any separate SendPortal Core package may have their own terms, which the README does not enumerate.

SendPortal Compared with SendPortal Core

The real alternative described by the README is not another newsletter vendor. It is SendPortal Core, the package extracted from the same project for applications that already have user authentication. The difference is the application boundary: SendPortal Core supplies core email marketing functionality, while the full SendPortal repository supplies a stand-alone application with its own authentication and workspace management.

Choose the full application when the operator wants to host a complete newsletter service and manage users and workspaces through the provided application. Choose SendPortal Core when an existing application already owns authentication and the operator wants to add email marketing behavior without adopting the full stand-alone wrapper. The README does not document feature parity between the two forms beyond identifying Core as the core functionality, so an integration team should verify which reports, workspace controls, and administrative screens belong to the complete application.

A hosted email marketing service could avoid PHP and database administration, but the README and repository files do not compare SendPortal with any named hosted alternative in terms of pricing, deliverability, analytics, or compliance. Such claims should not be inferred from the project's self-hosted description.

Editorial conclusion

Organizations that need a stand-alone newsletter system and already operate PHP infrastructure should assess SendPortal against the official v4 installation guide, especially delivery-provider requirements, database choice, and the boundaries between this application and SendPortal Core. Projects that only need campaign logic inside an existing authenticated Laravel application should inspect SendPortal Core instead. For PHP 8.2 or Laravel 10 and 11 users, the version choice is already defined: the README directs them to SendPortal V3 rather than V4. The concrete adoption boundary is whether the stand-alone application, including authentication and workspace management, matches the required operating model.

Frequently asked questions

Official sources

1. License: MIT
2. mettle/sendportal on GitHub
3. Project website
4. README
5. Releases