Deploying Hi.Events

Hi.Events offers flexible deployment options for both cloud and self-hosted environments. Whether you’re looking for a quick setup or a fully customized configuration, this guide will help you get up and running.

Overview

Hi.Events consists of two main components:

• Frontend: A Node.js React application that handles the user interface
• Backend: A Laravel PHP application that powers the API and business logic

You can deploy these components either:

• Together using our all-in-one Docker image (simplest approach)
• Separately for better scalability and control (recommended for production)

Deployment Options

One-Click DeployDocker DeployManual Setup

One-Click Cloud Deployment

The fastest way to deploy Hi.Events is through our verified cloud partners:

💡

Production Considerations

While one-click deployments are convenient for getting started, production environments require careful configuration of:

• Server resources based on expected traffic
• Database size and performance
• Security settings and environment variables
• Proper file storage configuration

Environment Variables

To configure your Hi.Events deployment properly, you’ll need to set up several environment variables. These control everything from database connections to email delivery settings.

Frontend Variables

Frontend Branding (Optional)

These are all optional — leave them unset to use the Hi.Events defaults.

Cookie Consent & Analytics (Optional)

Leave these unset to keep the default behaviour: no consent banner, and organizer tracking pixels load as soon as an event page opens.

Backend Variables

Mail Configuration

You can use email providers like Postmark, SendGrid, or AWS SES.

API-based mail providers

The MAIL_HOST / MAIL_PORT / MAIL_USERNAME / MAIL_PASSWORD variables above only apply when MAIL_MAILER=smtp. If you’d rather use a provider’s API, set MAIL_MAILER to the provider name and supply its credentials instead:

For more details on configuring mail settings in Laravel, refer to the Laravel Mail Documentation.

Stripe Configuration

For more information on obtaining Stripe API keys, visit the Stripe API Keys Documentation.

Setting up the Stripe webhook

For Stripe to work correctly, you need to set up the webhook in your Stripe dashboard:

1. Go to https://dashboard.stripe.com/webhooks
2. Click “Add endpoint”
3. Set the webhook URL to your backend’s Stripe webhook endpoint (see the note below): https://your-app.com/api/public/webhooks/stripe
4. You should listen for the following events:

• payment_intent.succeeded
• payment_intent.payment_failed
• charge.succeeded
• charge.updated
• charge.refunded
• refund.created
• refund.updated
• account.updated
• payout.paid
• payout.updated

General Configuration

Generate the APP_KEY using:

echo "base64:$(openssl rand -base64 32)"

Generate the JWT_SECRET using — note there is no base64: prefix here, unlike APP_KEY:

openssl rand -base64 32

Error Reporting and Logs (Optional)

Hi.Events can report errors — and optionally forward log records — to Sentry from both the backend and the frontend’s server-side rendering process. Leave the DSNs unset to disable it entirely.

Backend:

Frontend (the SSR server — these are read by frontend/server.js, not the browser, so they have no VITE_ prefix):

The SSR integration is configured to send as little as possible — user info, cookies, headers, request bodies, and query strings are all excluded.

Address Autocomplete (Optional)

Hi.Events v2 supports venue address autocomplete powered by Google Places. This is optional — without it, organizers can still enter venue addresses manually.

SaaS Configuration

The SAAS fee variables seed the initial default platform fee configuration. They are not read on every order, so changing them later has no effect on existing organizers.

At checkout, the fee rates are read from the organizer’s assigned configuration (organizer_configurations.application_fees), which every new organizer inherits from the system default.

To change the rates after deployment, update the application_fees values on the relevant organizer_configurations row. Editing the system default row changes the rates inherited by organizers still using it.

The Platform Fees sections in Organizer Settings and Event Settings do not set rates — they only control who pays the fee. Organizer Settings sets the default for newly created events; Event Settings overrides that for a single event.

Event Moderation (Optional)

Hi.Events can run newly published events through an automated spam check. When an event is flagged, it’s moved to a PENDING_MANUAL_REVIEW status — hidden from the public and locked from status changes — the organizer is emailed, and a notification goes to APP_PLATFORM_SUPPORT_EMAIL for an admin to approve or confirm from the admin area.

To re-run the check across existing live events — after changing the threshold, for example — use:

php artisan events:recheck-spam

AWS Configuration

These variables are required if you’d like to use AWS S3 for file storage. You can also use other s3-compatible services like DigitalOcean Spaces.

Database Configuration

You can either set individual database configuration variables or use the DATABASE_URL to simplify the configuration.

Redis Configuration

Queue Configuration

Cache and Session Configuration

Database Setup and Migrations

Hi.Events won’t start until its database schema has been created. Migrations must also be re-run after every upgrade.

The all-in-one Docker image handles this for you: its startup script runs php artisan migrate --force (and aborts startup if migrations fail) followed by php artisan storage:link on every container start. No action is needed.

For separate image deployments and manual setups you must run these yourself. The hi.events-backend image does not migrate on its own by default. (It is built on serversideup/php, so setting AUTORUN_ENABLED=true enables that base image’s opt-in automations, including migrations — but don’t rely on this unless you’ve configured it deliberately.)

Once your database environment variables are configured, run from the backend directory:

php artisan migrate --force

Then, only if you’re using local disk storage (FILESYSTEM_PUBLIC_DISK=public), create the symlink that makes uploaded files publicly reachable:

php artisan storage:link

If you’re running the backend in a Docker container, run these via docker exec:

docker exec your-backend-container php artisan migrate --force
docker exec your-backend-container php artisan storage:link

Running a Queue Worker

If you set QUEUE_CONNECTION to anything other than sync, a queue worker must be running or queued work — emails, webhooks, and occurrence generation for recurring events — will never be processed.

The all-in-one Docker image runs a worker automatically via Supervisor. For separate image deployments or manual setups, run:

php artisan queue:work --queue=default,webhook-queue,occurrences --sleep=3 --tries=3 --timeout=60

Keep this process alive with a process manager such as Supervisor or systemd. See the Laravel Queues documentation for details.

Running the Scheduler

Hi.Events uses Laravel’s task scheduler for recurring background tasks. If the scheduler isn’t running, these features won’t work:

The all-in-one Docker image (daveearley/hi.events-all-in-one) runs the scheduler automatically — no extra setup needed.

For separate image deployments or manual setups, you need to add a single cron entry on the server running your backend. This cron job calls Laravel’s schedule:run command every minute, and Laravel decides internally which scheduled tasks are due:

* * * * * cd /path-to-your-backend && php artisan schedule:run >> /dev/null 2>&1

Replace /path-to-your-backend with the actual path to your Hi.Events backend directory. If you’re running the backend in a Docker container, you can add this to the container’s crontab or run it via docker exec:

* * * * * docker exec your-backend-container php artisan schedule:run >> /dev/null 2>&1

You can verify the scheduler is working by running php artisan schedule:list — this shows all registered scheduled tasks and when they’re next due.

For more details on Laravel’s scheduler (daemon mode, running without cron, etc.), see the Laravel Scheduling documentation.

Important Deployment Considerations

If you’re planning to host events that might experience sudden bursts of traffic (like popular ticket sales or flash sales), you’ll want to take extra precautions with your deployment: