Which MISP install fits your team: Docker or native
For a team hosting MISP 2.5 on Ubuntu 24.04, the project's own installer script is the default choice, and misp-docker is the right choice when you want containers or when your operating system is not supported by the install scripts. The MISP download page recommends deploying MISP 2.5 either with the provided Ubuntu 24.04 installer script or with the misp-docker project, and it recommends a dockerized installation whenever the install scripts do not support your operating system. The MISP 2.4 install guides are marked end of life, so a new deployment should not start on 2.4 at all.
The native installer fits a team that runs Ubuntu 24.04 servers, already patches them through standard OS tooling, and wants MISP's PHP, MySQL or MariaDB and Redis components on the host where its own administrators can inspect them. misp-docker fits a team that already operates Docker Compose, wants NGINX, MISP modules, Redis, MariaDB and Exim4 separated into their own containers, and expects to update by pulling new images. Choose Docker only after confirming that your container host policy, image registry and backup process cover the volumes and the .env file that the misp-docker README asks you to create from template.env.
If your servers run an operating system the installer does not support, Docker is not a preference but the practical path. Existing 2.4 users on Ubuntu 24.04 or older should follow the download page's instruction to upgrade the distribution to 24.04 and run the provided upgrade script, so check your current OS version before you pick an approach. Ask your platform team to confirm whether they can run Podman, since the misp-docker README marks Podman as experimental and not supported, and plan for Docker Engine where a supported path is required.
How the native and Docker installs compare
This table sets the MISP installer script on Ubuntu 24.04 against the misp-docker images across the factors that shape day-to-day operations. Read each row as a question to answer for your own environment, and treat any cell marked for confirmation as an open item to raise with the MISP project before you commit.
| Factor | Native installer script | misp-docker images |
|---|---|---|
| Supported operating system | Project recommends Ubuntu 24.04 with the provided installer script for MISP 2.5 | Recommended when the operating system is not supported by the install scripts; works on hosts that run Docker |
| Component layout | MISP, database, Redis and web server run as services on the host | MISP core and modules split into separate images, with NGINX, Exim4, Redis and MariaDB as separate containers |
| Configuration entry point | Installer and host configuration files | A .env file copied from template.env drives the deployment |
| Upgrade method | Upgrade script for Ubuntu; 2.4 users must move to Ubuntu 24.04 first | Keeping images current is described as a docker compose pull |
| Scaling behavior | Scaling is a host-level design decision; confirm the supported pattern with the project | Project guidance covers running multiple misp-core containers behind a load balancer |
| High availability options | Confirm with the MISP project which HA patterns are documented for the installer | Multi-container layout with a load balancer is documented; confirm database and Redis redundancy with the project |
| Dependency management | Host packages and PHP, MySQL or MariaDB and Redis are installed and patched on the host | Off-the-shelf Exim4, Redis and MariaDB images are pinned and updated through image tags |
| Podman support | Not applicable | Marked experimental and not supported by the misp-docker README |
| Licensing | MISP is AGPL-3.0; taxonomies and galaxies are CC0 or BSD-2-Clause, separate from the software license | Same MISP AGPL-3.0 software license; confirm the license of the optional MISP-Guard container before use |
What misp-docker splits MISP into
The misp-docker project breaks a MISP deployment into separate containers, each with its own image, update path and failure mode. Knowing which container does what tells you where to look when something breaks and what you must maintain yourself compared with a single host installed by the installer script.
misp-core container
The misp-core image carries the MISP web application and its background processing. It is the image you scale when you run several copies behind a load balancer, and the one most teams will update first. Check which database and Redis endpoints each copy points to, because all copies must share the same state. Confirm the scaling guidance in the misp-docker README before you add replicas.
misp-modules container
MISP modules run as their own misp-modules image, separate from the core application. Enrichment, import and export modules are the parts most likely to call external services, so their network egress and outbound rules deserve a separate review. Decide whether your team will enable only the modules it needs, and test module upgrades on their own rather than assuming the core image covers them.
NGINX as a separate image
The misp-docker project runs NGINX in its own container in front of MISP. TLS termination, certificate handling and request limits therefore live in the proxy configuration, not in the application image. Ask your security team who owns the certificates and how renewals reach the container, because a native install usually places that work on the host.
Exim4, Redis and MariaDB images
Mail delivery, caching and the relational database come from off-the-shelf Exim4, Redis and MariaDB images rather than custom builds. This keeps those components on upstream release cycles, which is useful for patching, but it means your backup, retention and restore process must cover the database and Redis volumes explicitly. Confirm the MariaDB version your team will standardize on before you plan upgrades.
Optional MISP-Guard container
MISP-Guard is an optional container listed in the misp-docker README. Treat it as a separate component with its own purpose, configuration and review. Only enable it after you have written down what it filters and who approves changes to its rules. If your environment does not need it, leave it out of the stack and record that decision.
The .env file and Podman status
Deployments are configured through a .env file copied from template.env, so environment settings stay in one reviewable place. Keep that file in version control with secrets handled outside it. The README marks Podman as experimental and not supported, so if your platform standard is Podman, confirm support with the MISP project before choosing this path.
How the native Ubuntu 24.04 installer sets up MISP
The provided Ubuntu 24.04 installer script is the path the MISP project recommends for a native deployment of MISP 2.5. The MISP download page recommends deploying MISP 2.5 with this script or with the misp-docker project, so a native install is a first-class choice rather than a fallback. The script installs MISP onto the host operating system, which means the web server, PHP, MySQL or MariaDB, Redis and the MISP application code all live on that one machine and are managed with the host's packages and services. Before you run it, confirm that your target host is Ubuntu 24.04 and that your patching process can handle the OS-level packages the script pulls in, since those become part of your change control.
The download page also lists other native routes. A NUKIB Docker image based on CentOS Stream 8, a Puppet module for CentOS 7, an Ansible role and RPM packages are all documented options. Teams standardized on Red Hat family systems should check whether these routes still match their operating system versions before committing, because the page ties each one to a specific distribution. The download page is explicit that when an operating system is not supported by the install scripts, a dockerized installation is the recommended route. If your estate runs another distribution, that guidance points you toward misp-docker, and the choice should be made before any hardening or configuration work begins. Confirm the current support matrix directly with the project at MISP download and install.
How each install is upgraded, backed up and monitored
This table compares the day-two work for a native MISP 2.5 install and a misp-docker deployment: how each is upgraded, who owns backups and monitoring, and which skills the team needs. Read it as a checklist of duties to assign before choosing, since the project documents the upgrade paths but leaves backup and monitoring design to the operator. The main takeaway is that both paths shift work to your team, just into different skill sets.
| Area | Native install (installer script) | misp-docker deployment |
|---|---|---|
| Routine upgrade path | Follow the project's upgrade process for the installed release. Existing 2.4 installs on Ubuntu 24.04 or older are directed to upgrade the distribution to 24.04 and run the provided upgrade script. | Edit the image tag in the .env configuration, then run docker compose pull to fetch current images. The README says keeping images current should be as simple as this. |
| Legacy 2.4 installs | The 2.4 install guides are marked end of life. Confirm the exact OS upgrade and script steps in the project's download documentation before scheduling work. | Confirm with the misp-docker project whether a 2.4 to 2.5 move is an image change or a data migration. Test on a copy of the database first. |
| Database changes | Confirm how the 2.5.47 database migration system applies to your existing MariaDB or MySQL data, and plan a snapshot before each upgrade. | Schema changes run against the containerized database volume. Confirm rollback steps for the database volume, not only the image tag. |
| Backup ownership | Your team owns backups of the MySQL or MariaDB database, the MISP file directories and configuration, at the host or storage layer. | Your team owns backups of the named Docker volumes, the .env file and the database and Redis data, using container-aware tooling. |
| Monitoring responsibility | Host metrics, service status and MISP worker health are checked on the host with standard Linux tooling and logs. | Container health, restarts and resource limits are checked through Docker tooling, alongside application logs from misp-core and misp-modules. |
| High availability | Running several misp-core instances behind a load balancer is not described for native installs in the supplied material. Confirm the approach with the project. | The README gives guidance for multiple misp-core containers behind a load balancer. Your team still designs shared database, Redis and file storage. |
| Rollback after a failed update | Restore from host-level snapshots or backups taken before the change. Confirm the supported rollback path in the project documentation. | Return to the previous image tag and restore volumes from backup. Podman is experimental and not supported, so plan on Docker. |
| Skills required | Linux administration, package and service management, PHP and web server troubleshooting, and database administration. | Docker Compose, container networking, volume management and NGINX reverse proxy configuration, plus enough Linux to debug the host. |
| Quote questions | Ask who runs the OS and patch cycle, who restores the database, and whether the upgrade script is included in scope. | Ask who maintains the .env, image pinning, volume backups and load balancer design, and whether container monitoring is in scope. |
What happens to existing MISP 2.4 installs
This sequence moves a legacy MISP 2.4 instance onto the supported 2.5 line without losing sharing history or configuration. Each step ends with a check you can record before the next one starts. Treat the work as a planned migration, not a routine patch.
Confirm the 2.4 install is end of life
Start by recording the MISP version, the operating system and the install method currently in use. The MISP download page marks the 2.4 install guides as end of life, and the 2.4 line now receives security fixes only, with 2.4.221 released on September 17, 2026. Your team, or DeployOpen if it is engaged, should write down that the instance is on a security-fix-only branch. The output is a short inventory that names the version, host OS and owner, which becomes the baseline for the rest of the plan.
Check the host operating system
The MISP download page tells existing 2.4 users on Ubuntu 24.04 or older to upgrade the distribution to 24.04 before running the provided upgrade script. Confirm the exact release of the host and whether it is covered by the upgrade path. If the host is on an unsupported or non-Ubuntu system, the download page points to a dockerized installation as the alternative. The output is a decision recorded as either an in-place distribution upgrade to 24.04 or a rebuild on a new host, with the reason written down.
Back up the database, files and configuration
Take a full backup of the MISP database, the attachments and configuration files before any upgrade step. Include the sync and sharing group settings, API keys, and any custom plugins or modules you run. Test a restore of the backup on a separate system so you know it works. The output is a verified restore on a staging host, which confirms that a rollback path exists if the upgrade fails. Ask whoever runs your backups to confirm the restore test was performed.
Plan for the 2.5.47 database migration
MISP 2.5.47, released on September 17, 2026, introduced a new database migration system with PostgreSQL support. Read the 2.5 release notes for changes to the database engine, schema migrations and any plugin compatibility issues. Decide whether you will stay on MySQL or MariaDB during the move or take the PostgreSQL option as a separate project, since changing engines adds migration work. The output is a written decision on the database engine, with the release notes reviewed and the list of plugins and integrations that need compatibility checks.
Run the provided upgrade script in staging
Apply the Ubuntu 24.04 upgrade script to the staging copy of the instance, following the MISP download page. Run the upgrade against the restored backup rather than the live system. Review the output for errors and confirm the MISP web interface, API and sync connections come up. The output is a staging instance on the 2.5 line with a log of every step, which becomes the reference for the production run.
Validate sync, API and sharing behavior
Test the functions your partners depend on: event synchronization with other MISP instances, distribution levels and sharing groups, API queries through the REST interface and any exports used by your detection tools. Compare results with the 2.4 production instance wherever possible. The output is a signed test checklist that lists each function, the expected result and the actual result, with any gaps assigned to an owner before production cutover.
Cut over production and retain the rollback path
Schedule the production upgrade with the teams that consume MISP feeds and sync, since the instance may be unavailable during the change. Apply the same steps used in staging, then repeat the validation checklist on the live system. Keep the 2.4 backup and the restore procedure available until the 2.5 instance has run stably for a period your change board sets. The output is a production instance on 2.5, a closed change record and a documented rollback decision, which ends the legacy 2.4 install.
Decide on containers for future operations
Once the instance is on 2.5, record whether it will continue as a native install or move to the misp-docker project. The misp-docker README describes production ready images and says image updates can be applied with docker compose pull, but a move to containers is a separate migration with its own testing. Ask your platform team and, if engaged, DeployOpen to confirm the operating model before any change. The output is a written operating decision that states the installation method, the owner of upgrades and the next review date.
High availability options under each install
The misp-docker README gives guidance for running multiple misp-core containers behind a load balancer, which is the most concrete high availability path in the documented sources. The pattern places several misp-core containers behind a shared entry point while the rest of the stack, including NGINX, Redis, MariaDB and Exim4, runs as separate services. Because the README covers the container layout, you can plan the topology around it, but the README does not settle every design question for a production cluster.
- Load balancer placement: Multiple misp-core containers sit behind a load balancer, so the balancer, its health checks and TLS termination need an owner.
- Separate services: NGINX, Redis, MariaDB and Exim4 run as their own containers, so each one needs its own availability plan rather than being assumed to follow the core containers.
- Configuration consistency: All core containers read the same
.envsettings, so changes must be rolled out to every instance in the same way. - Upgrade path: The README says keeping images current should be as simple as
docker compose pull, but a multi-node pull and restart sequence needs a tested rollout plan. - Podman limits: The README marks Podman as experimental and not supported, so a container runtime choice affects what the project will support.
Confirm the HA design, shared session and file storage, and database replication with the MISP project through its support page and with your own architects before you commit to this topology.
The native path, using the Ubuntu 24.04 installer script recommended for MISP 2.5, is documented for a single installation built from the script. The download page does not describe a multi-node or load balanced reference architecture for native installs, so any clustering would be a custom design your team owns. Teams that already run Ubuntu fleets sometimes prefer this model because it uses familiar host tooling, but availability has to be built around the host rather than taken from the project's documentation.
- Single host baseline: The installer script targets one server, so redundancy depends on your own host, storage and failover tooling.
- Undocumented clustering: The sources reviewed for this page do not describe a native multi-node layout, so treat any cluster as your design.
- Backup and restore: Recovery time depends on how quickly you can rebuild the host and restore the database and files.
- Hypervisor or cloud failover: Host-level failover, such as virtual machine restarts, can cover some outages but does not replace application-level redundancy.
- Upgrade ownership: Upgrades follow the project's upgrade process for the host, and your team schedules the maintenance window.
Ask the MISP project which native topologies it has tested before you assume a clustered native install is supported.
Whichever install you choose, high availability depends on how sessions, uploaded files and the database behave when more than one application node is running. The topic sources describe MISP as built on PHP with CakePHP, MySQL or MariaDB and Redis, and the MISP 2.5.47 release introduced a new database migration system with PostgreSQL support. These facts matter for availability planning, but the sources reviewed here do not spell out the session, file or replication design for a cluster, so those choices need explicit confirmation.
- Session handling: Sessions must stay valid when a request lands on a different core node, so the session store needs a deliberate design.
- File storage: Attachments and exported files must be reachable from every node that serves them.
- Database replication: MariaDB or MySQL replication, failover and read routing are your decisions to make and test.
- Redis placement: Redis usage in your topology determines whether a cache or queue failure affects logins or processing.
- PostgreSQL support: The 2.5.47 release notes mention PostgreSQL support, so confirm whether it is production ready for your version before choosing it.
Review these points with the MISP project and your architects before any cluster goes into production.
Availability requirements should be written down before any install method is chosen, because the documented sources cover container layout and single-host installation but not a complete high availability reference. A clear requirement sets the acceptable downtime, the recovery steps and who runs them, and it shows which parts of the design you must build and test yourself. Without that, a team can end up with a load balanced front end that still depends on one database or one file store.
- Availability target: Define the outage tolerance and recovery expectations your sharing workflows actually need.
- Component map: List every stateful service, including database, Redis, file storage and mail relay, with its failover method.
- Support boundary: Ask the MISP project which configurations it supports in production, including any Podman or native clustering questions.
- Test plan: Schedule failover and restore tests that run against the chosen topology, not only against a single node.
- Ownership: Name who operates the load balancer, database and storage, and who answers during an incident.
Use the MISP download page to confirm the supported install methods before you finalize the topology.
Questions teams ask before choosing a MISP install method
Can we run misp-docker in production?
Yes, the misp-docker README describes its images as production ready, so the project itself does not treat containers as a lab-only option. The detail that matters is what you operate: misp-core, misp-modules, NGINX, Exim4, Redis and MariaDB run as separate containers, and you own the volumes, backups, TLS, load balancing and monitoring around them. Teams that already run container platforms with image scanning and change control usually find this familiar. Teams without that practice should confirm who will patch the base images and how a failed upgrade is rolled back before committing. A quote from DeployOpen starts from a written scope that names your container host, storage and recovery targets.
Is Podman supported for running MISP containers?
No, not as a supported option. The misp-docker README marks Podman as experimental and not supported, so the project will not guarantee behavior on it. If your standard is Podman, you can still evaluate it, but treat it as a compatibility test rather than a production path. The MISP download page recommends a dockerized installation when an operating system is not supported by the install scripts, so a Docker host or the Ubuntu 24.04 installer may fit better. Confirm your container runtime requirements with your platform team before the scope is agreed, since a runtime change later affects the upgrade and support model.
How do we upgrade from MISP 2.4 to 2.5?
Plan a move to MISP 2.5 rather than an in-place upgrade of the 2.4 install guides, which the MISP download page marks as end of life. The page tells existing 2.4 users on Ubuntu 24.04 or older to upgrade the distribution to 24.04 and then run the provided upgrade script. If your host is older, the distribution upgrade comes first and is often the largest task. Check your current 2.4 build, your database, custom plugins and any sync partners before the work starts. MISP 2.5.47 introduced a new database migration system with PostgreSQL support, so review the release notes for changes that affect your database plan.
Who runs the MISP upgrade and what does it cost in effort?
Either your team or a services partner runs the upgrade, and the effort depends on the drivers below, not on a fixed number. Effort rises with the distribution gap, the number of custom modules and integrations, the size of the event database, the number of sync connections to trusted partners, and how much testing your sharing communities require. Costs are one-time for the migration and recurring for the staff time to keep images or packages current. On the container path, routine updates are meant to be a pull and redeploy, but you still need test runs before production. Ask any provider for a written scope listing the source version, target version, environments and acceptance tests, then compare quotes against that same scope.
Can our team install and run MISP without outside help?
Often yes, if you have Linux administration skills and someone who owns the database, TLS, backups and the sharing configuration. The MISP project provides the installer script, the misp-docker project and documentation, so the work is achievable in-house. The risks are less about the first install and more about ongoing ownership: patch cadence, upgrade testing, incident response for sync problems and recovery from failed migrations. Before deciding, list who will cover those tasks for the life of the platform, including absence and turnover. If the gaps are real, a fixed-scope engagement can cover the build, hardening, documentation and handover, with ongoing support available as a retainer.
What does a DeployOpen engagement cover for MISP?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which applies to MISP installs on either path. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. To request a quote, describe your current MISP version, hosting, integrations, sync partners and the outcome you need, and ask for the scope in writing.
Does the misp-docker setup support high availability?
The misp-docker README gives guidance for running multiple misp-core containers behind a load balancer, so a horizontally scaled web tier is documented. High availability also depends on the database, Redis, shared file storage and scheduled jobs, which the README does not fully resolve for you. Confirm how your design handles database replication, session state and background tasks before you count on failover. Ask the vendor or project for the tested topology, and have your own team validate failover in a non-production environment.
What drives the cost of running MISP yourself
MISP itself carries no license fee. The software is licensed under AGPL-3.0, so the money you spend goes to the people who build, run and keep the instance current, the infrastructure it runs on, and the backup and monitoring around it. Whichever install path you choose, the recurring cost is staff time for patching, upgrades, feed and sync housekeeping, and user administration. The one-time cost is the initial build: the installer or Compose setup, TLS, authentication, the sharing and sync configuration, and the first documented runbook. Ask any implementation partner to separate those two buckets in a quote so you can see what you pay once and what you pay every year.
Infrastructure and HA are the largest variables. A single-node install on one virtual machine is a small, predictable line item. A multi-container deployment with several misp-core containers behind a load balancer, a separate database tier, Redis and mail relay adds hosting, load balancer, storage and monitoring costs, plus the engineering time to test failover. Ask whether the quote includes the database backup strategy, restore testing and retention settings, and whether monitoring covers container health, disk growth, sync failures and feed errors. Confirm which of these your own platform team already runs, because duplicating an existing backup or monitoring stack is a cost you can avoid.
Upgrade effort is the cost most often underestimated. MISP 2.5 is the recommended line for new deployments, and the 2.4 line is end of life with security fixes only, so an existing 2.4 estate carries a migration project on top of routine patching. Ask the quote to state who performs the distribution upgrade and the upgrade script on Ubuntu, how the test environment is rebuilt before each release, and whether post-upgrade validation of sync and API consumers is included. Also ask whether a retainer covers recurring upgrades and continuous monitoring, and what it excludes. Quotes that name the scope in writing are easier to compare than hourly estimates.
How DeployOpen plans and runs MISP deployments
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For MISP, that means choosing the installation path against your operating system, hosting model and upgrade plans, then building and documenting it in your environment.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states the target MISP version, operating system, container or native path, and hosting environment.
- We confirm which sharing communities, authentication method and upgrade process the deployment must support.
How we build
- Installation is carried out in your cloud account, data center or air-gapped network, following the path chosen in scope.
- Configuration covers database, Redis, the web tier and any load balancer or NGINX layer, as the chosen path requires.
- Hardening and testing are documented against the agreed scope, with any gaps listed for your decision.
How we hand over
- Deliverables include runbooks for installation, upgrade, backup and restore, written for your operations team.
- Handover covers the configuration files, secrets handling and the steps used to verify the deployment.
- You receive a list of open items, including anything to confirm with the MISP project or your own security team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers.
- Retained support can cover MISP upgrade planning when new releases or the 2.4 end-of-life path affect your deployment.
- DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit report or certification.
