Operator-grade configuration. Every behaviour, exposed.

Settings → Application Settings. From there the page opens into tabs — General, Mail, Domains, Contacts, Campaigns, Notifications, Performance, and Billing (if the One Panel addon is installed). Each tab covers a domain of behavior. Cron Settings is a sibling page at Settings → Cron Settings, and Global Headers at Settings → Global Headers.

No — every setting has a sensible default. Out of the box, the installation works for typical mid-volume sending without configuration. You touch Application Settings when you need to deviate: enabling HTTPS for production, tuning log retention for compliance, adjusting cron intervals for higher-volume throughput, configuring webhooks queue mode for production reliability. Most senders touch a handful of settings at install and leave the rest.

Queue Driver = Database vs Sync. Database queues jobs and processes them separately from the web request (recommended for production). Sync processes jobs DURING the web request (debugging only — one slow webhook makes everything unresponsive). Database driver then needs a processing mode: Realtime (immediate, more processes), Cronjob (intervals via the platform cron, predictable load), Supervisor (managed worker processes, best for high-volume). Production high-volume installations should use Database + Supervisor.

Settings → Global Headers → Add. Pick a header name (typically X-prefix for custom headers per RFC convention), enter the value. The platform injects the header into every outgoing email. Useful for X-Campaign-Source, X-Tenant-ID, X-Cost-Centre, or anything that helps downstream attribution. Per-Package additional headers in User Packages stack on top of these globals.

Many of them, yes. Application Settings define INSTALLATION-WIDE behavior; Packages can override behavior for Users on that Package; Users can override behavior for individual scoping; Campaigns can override behavior for individual sends. The override hierarchy is documented per setting — generally: Installation > Package > User > Campaign, with the most-specific value winning.

Yes — every cron job has its own interval setting. The platform docs include volume-based guidance: High Volume installations (100k+ emails/day) tune click/open tracking down to 10 seconds, queue work to 30 seconds; Medium Volume relaxes those to 30s and 2-3 minutes; Low Volume can run most jobs at 5-15 minute intervals. Run Now and Run Forcefully buttons let you trigger jobs manually for testing or emergency processing.

Your server's cron daemon calls Mumara's scheduler every minute via a single crontab entry. Inside that, Mumara's scheduler checks which jobs are due based on each job's configured interval and runs them. So you don't add 18 crontab entries to your server — just one — and Mumara handles the scheduling internally. The Verifying Cron section of the docs explains how to confirm the server-cron-to-Mumara link is healthy.

Campaigns auto-pause when a binding limit hits (quota cap, sending-node failure, hourly window exhausted). The pause is recorded with the trigger reason. If 'Automatically resume auto-paused campaigns' is enabled on the Campaigns tab, the platform automatically resumes the campaign when the binding window resets — next hour for hourly caps, next day for daily, or when the node comes back up. Operations teams typically leave auto-resume ON to avoid manual intervention for routine pauses.

Yes — notifications can be toggled at the system level (Application Settings → Notifications tab) for installation-wide defaults, AND each Admin has their own notification preferences in their profile. So you can run defaults for the team while letting individual admins opt into / out of specific notification types based on their role (deliverability admin wants bounce-rate alerts; marketing admin doesn't).

Billing tab is part of the One Panel billing addon — credit-based billing for reseller installations. Credit-per-email pricing, negative-credit handling, invoice thresholds, credit-related campaign behaviour (block at zero credits vs allow overuse). Only relevant if you're reselling Mumara to your own customers with metered billing. See User Packages for the package-tier integration.