How n8n security automation with MISP and TheHive fits a SOC workflow
A security team that receives indicators in MISP and tracks investigations in TheHive often moves data between the two by hand. n8n can sit between them to enrich, route and notify, so an indicator arriving in MISP can be checked against other sources, turned into a case in TheHive when it meets agreed criteria, and announced to the analysts on duty. This page covers that integration path, but the research behind it does not confirm dedicated MISP or TheHive nodes in n8n. Before you design around a named node, check n8n's node documentation for each product. If a dedicated node exists, confirm which operations it supports. If it does not, plan for HTTP Request calls against each product's API, and confirm the endpoints and authentication method in the versions you run.
Settle the license question before the build starts. n8n is source-available under the Sustainable Use License. It is not OSI open source. The license permits use or modification for your own internal business purposes, along with non-commercial or personal use. A SOC running n8n to enrich its own alerts and open its own cases fits the internal-use case, but have your legal or procurement team confirm that reading against the license text. The answer changes if the workflows run for customers, for a managed service model or for partner organizations. Also check the code you deploy for any file with .ee in its name or directory, because those files require a valid n8n Enterprise License.
Most of the design effort goes into the workflow logic, not the connectors. Decide which MISP events or attributes start a workflow, for example by tag, distribution level or event type, and confirm how your MISP instance can notify n8n of new or updated items. MISP's restSearch API and PyMISP library are the documented ways to query for changes. Decide where enrichment runs and what happens when an enrichment source fails. Give each TheHive case a stable reference to its MISP source, so a repeated trigger updates the existing case instead of opening a duplicate. Store the MISP and TheHive API keys in n8n's credential store, and remember that in queue mode the encryption key must be shared with every worker and webhook processor.
Test the workflow with sample events in a non-production instance before any analyst receives a notification. Review the failed executions log, confirm that notifications reach the right channel, and record which distribution levels may flow into which destinations. A dedicated SOAR platform fits better when analysts need to build and maintain playbooks themselves, when approval steps and case-native actions are central to the process, or when the team wants an app model with its own versioning. Shuffle is one option to evaluate. Its documentation describes a self-hosted runtime, OpenID Connect and SAML sign-on, and apps built from OpenAPI specifications. Compare the two against the number of playbooks you expect to maintain, the people who will maintain them, and the support you need.
What n8n security automation needs before the first workflow
Six items need decisions before any workflow runs: the MISP version, the n8n edition and license, a TheHive API account, network paths between the platforms, the queue mode key and database design, and the current node and API versions. Each card names what to confirm and who should confirm it.
MISP 2.5 for new deployments
Install MISP 2.5, the version the project recommends for new deployments. MISP 2.4 is end of life and receives security fixes only, and the project strongly advises against installing new 2.4 instances. Your n8n MISP steps will call the MISP API, so confirm the MISP version and the scope of the API key before you build enrichment steps. The project recommends Ubuntu 24.04 with its provided installer, and lists Docker images, Ansible roles, Puppet and RPM packages as other options.
n8n edition and license terms
Choose the n8n edition that will run the security workflows before anything else. The free Community edition is self-hosted, but n8n is source-available under the Sustainable Use License, which allows use for your own internal business purposes and limits distribution. Files with .ee in their name need a valid n8n Enterprise License. Ask legal to confirm that your intended use, including any use for other organizations, fits those terms.
TheHive instance and API account
Provision a TheHive instance that n8n can reach, along with a dedicated API account for the workflows. Scope the account to the organizations, case templates and case actions the workflows need, and store its key only in n8n credentials. Confirm with TheHive which release and API behavior your instance runs, because the n8n TheHive node depends on both. Record who owns the account and how its key is rotated.
Network paths to MISP and TheHive
Map each path n8n needs before the first run: outbound HTTPS from n8n to the MISP API and to the TheHive API, including any reverse proxy or certificate chain each platform presents. Confirm that webhook endpoints accept traffic only from the systems that send alerts, and that enrichment lookups leave your network only when a third-party service is intended. Ask your network team to test each route with the same service account and TLS settings the workflow will use.
Encryption key and PostgreSQL for queue mode
If you plan queue mode or workers, settle the database and key design first. In queue mode, the main instance hands executions through Redis to workers that read and write PostgreSQL. Every worker and webhook processor must share the main instance's encryption key to access stored credentials, so a mismatched key breaks saved connections to MISP and TheHive. Keep the key in your secrets system alongside database backups. A single-instance setup can defer this decision.
Confirm current vendor versions
Check the current TheHive API version and the n8n MISP and TheHive node versions with each vendor before writing the first workflow. Node behavior and field names can change between releases, and n8n ships minor releases roughly weekly, so a version tested earlier may not match the current package. Pin the n8n version, record the node versions in your change records, and retest enrichment and case creation after each upgrade.
Which integration method MISP and TheHive support in n8n
For MISP, the integration surface is its REST API. MISP documents an OpenAPI-described API, and its restSearch endpoint is the main way to query events and attributes from outside the web interface. The project also bundles PyMISP, a Python library that wraps those calls. Before you build anything on HTTP Request nodes, check whether the n8n release you run includes a native MISP node and which operations it covers. List those operations in your instance, compare them with the enrichment and event creation steps in your playbook, and note the gaps you would have to build yourself. Record the MISP version too, because the API you test against must match the server you connect to. MISP 2.5 is the version the project recommends for new deployments.
The choice between a native node and generic HTTP calls comes down to who maintains the integration over time. A native node changes through n8n's own releases, so parameter names and authentication handling move with the node. HTTP Request calls leave that work with your team: you own the endpoint paths, headers, request bodies, restSearch pagination and response parsing. Error handling differs as well. A native node returns errors in a form n8n already understands, while an HTTP Request step returns whatever status and body MISP sends. You must decide how to treat a 403 from an expired key, a timeout or an empty result set, and whether a retry is safe. Version drift is the largest risk, since n8n ships minor releases roughly weekly and MISP moves on its own cadence.
TheHive is less settled. The research behind this page does not confirm which n8n node, if any, applies to TheHive, which authentication method it uses, or which API endpoints a given TheHive release exposes for alerts, cases, tasks and observables. Treat those three points as open until you have checked them yourself. Open the node list in your n8n version, read the credential fields the node asks for, and confirm the authentication method against the TheHive documentation for your release. Then test each endpoint your playbook needs against your own TheHive instance, because paths and payload shapes can change between TheHive versions. Record the TheHive version alongside the n8n version so that the next upgrade of either product starts from a known baseline.
A practical rule follows from this. Use a native node for each MISP or TheHive operation it covers completely, and fall back to HTTP Request only for the gaps. Wrap each fallback in a named sub-workflow with its own error branch, and add a note that records the product versions it was tested against. Store API keys in n8n credentials and keep them out of workflow expressions. Before going live, run read-only queries against a non-production MISP and TheHive, such as a restSearch for a known indicator and a case lookup, and confirm that the output fields your later steps depend on are present. Repeat those checks after every n8n, MISP or TheHive upgrade, because a workflow that passed earlier can fail silently when a field name or endpoint changes.
Configuring n8n security automation with MISP and TheHive in order
This sequence sets up separate, narrowly scoped MISP and TheHive identities for n8n, verifies each one with a read or a test case, and confirms that secrets stay in the n8n credential store. It gives the team a tested connection to both platforms before any enrichment or case workflow goes live.
Create a narrowly scoped MISP automation key
A MISP administrator creates a separate user for n8n and generates its automation key, assigning the lowest role that still permits the searches the workflows need. The role should not allow publishing, editing events or changing settings. Confirm the exact permissions available in your MISP version before assigning it, and record the account's owner and purpose. The step is done when the key authenticates against the MISP API and the account appears as a dedicated automation user, separate from any analyst account.
Store the MISP key in n8n credentials
An n8n administrator creates a MISP credential in n8n, entering the key and the MISP base URL, and saves it so that only the workflows that need it can select it. Do not paste the key into HTTP Request headers, expressions or workflow notes, because those fields are saved with the workflow. Ask whoever operates n8n to confirm that the encryption key is backed up, since stored credentials depend on it. The step is done when a test node using the credential runs without an authentication error.
Run a read-only restSearch test
Build a test workflow that calls MISP's restSearch endpoint with a narrow filter, such as one tag or a date window you already know contains events. Use the MISP node or an HTTP Request node that points at the same API, and make sure the call only reads data. Compare the returned event count with the count MISP shows in its interface for the same filter, then deactivate the test workflow. The step closes when the two counts match and the MISP event list is unchanged afterward.
Create a TheHive account with case rights
A TheHive administrator creates a dedicated API account for n8n and grants it only the permissions needed to create and delete cases. Confirm the permission names and role mapping in the TheHive documentation for your release before assigning them, and record the account's owner. Assign the account to the non-production organization used for testing. The step closes when the account authenticates to the TheHive API and holds no permissions beyond those planned.
Store the TheHive credential in n8n
An n8n administrator creates a TheHive credential in n8n with the API key and the TheHive base URL, and names it so that its purpose and target organization are clear to other editors. Restrict its use to the workflows that create cases. As with MISP, keep the key out of node parameters and expressions. The step is done when a test node using the credential connects to TheHive without an authentication error.
Test case creation and deletion in staging
In the non-production TheHive organization, run a workflow that creates a case with a clearly labeled test title, then deletes it using the case ID returned by the create call. Record that ID from the create response. Do not run these tests in an organization that analysts use for live work. The step closes when the create output includes a case ID, the delete step succeeds and the case no longer appears in the case list.
Confirm credentials stay out of exports
Export the test workflows as JSON from the n8n interface and search each file for the MISP key and the TheHive API key. The export should reference each credential by name and identifier and should contain no secret values. Repeat the search after any edit that adds a node or expression, because a pasted value in a field bypasses the credential store. Only workflows that pass this check should move toward production. The step closes when the search finds no secret values in either export.
How MISP attributes map to TheHive observables and cases
This table lists the MISP event and attribute fields the workflow reads, the TheHive field each one fills, and whether an n8n transformation is needed. Read the third column before building, because distribution checks must run before any data reaches TheHive and enumerated values must be confirmed against the TheHive version you run.
| MISP field | TheHive destination | n8n step and what to confirm |
|---|---|---|
| Event info | Case title | Prefix with the MISP event ID and truncate to the title length your TheHive version accepts. |
| Threat level | Case severity | Transformation required: build an explicit lookup table. Confirm the severity values in your TheHive version. |
| Distribution and sharing group | Not a TheHive field; gates whether the event is forwarded | Filter before case creation. Confirm the distribution values your MISP API returns for each event and attribute. |
| TLP tag (tlp taxonomy) | Case and observable TLP | Transformation required: map the tag to TheHive's TLP labels. Decide the default for untagged events and confirm the label set. |
| Other event tags | Case tags | Pass through, with a filter for tags that should not leave your organization. Confirm tag length and count limits. |
| Attribute type | Observable type | Transformation required: MISP type names do not match TheHive names one to one, so use a lookup. Confirm the observable types enabled in your TheHive version. |
| Attribute value | Observable data | Transformation required: normalize the value and split composite types such as filename|hash. Confirm how TheHive stores each data type. |
| Attribute comment and to_ids flag | Observable description and IOC flag | Copy the comment as the description. Confirm that your TheHive version exposes an indicator flag and how it is set through the API. |
Securing n8n security automation credentials and access
The n8n controls for this automation sit in four areas: the keys that connect n8n to MISP and TheHive, the encryption key that lets queue-mode workers read stored credentials, the plan that determines which login methods you can use, and the people and network paths that can change or trigger workflows. Review each area before the first analyst relies on a workflow.
Scope and rotate MISP and TheHive keys
Create a separate API key for each integration and each environment, and bind it to a service account that holds only the rights the workflow needs, such as reading events in MISP or creating cases in TheHive. Confirm in each product's documentation how keys inherit permissions and whether they can be limited by organization or profile. Set a rotation schedule that matches your security policy, record which workflows use each key, and test the replacement in a staging instance before revoking the old key.
Protect the n8n encryption key
In queue mode, the main instance's encryption key must be present on every worker and webhook processor so they can decrypt the credentials stored in the database. A missing or mismatched key stops those processes from using MISP and TheHive credentials, which often appears as failed executions with unclear errors. Store the key in your secrets manager, limit who can read it, apply it to each new node before it starts, and confirm the procedure for changing it in n8n's documentation before you need to.
Check SSO and LDAP against your plan
n8n's pricing page places SSO and LDAP in the Business and Enterprise plans only, so an instance on any plan without them signs analysts in with local accounts. Check your plan before you design the access model, because the login path depends on it. SAML setup guides exist for Okta Workforce Identity and Azure AD, so confirm your identity provider is covered and that account removal for leavers runs through it.
Restrict who edits credential workflows
Workflows that call MISP or TheHive hold analyst-facing credentials, so editing them is a privileged action. Keep edit rights with a small group of automation owners, give analysts run or view access only, and confirm which roles and project features your edition offers. Review credential sharing separately from workflow sharing, and remove access when someone changes teams. Review workflow versions before changes go live so a modified node cannot quietly send case data to a new destination.
Keep webhook endpoints inside the network
Webhook triggers that receive MISP or TheHive events should listen only on addresses your sending systems can reach internally. Do not publish them through a public route, and place the webhook processor behind a reverse proxy that restricts source addresses. Add a shared secret or signature check at the start of each workflow, and test that unauthenticated requests are refused. Ask your network team to document the exact paths, because a temporary exception often becomes permanent.
Log executions for review
Each workflow run records what it did, so keep execution history for the period your investigations and audits need, and decide who can open it, since execution data can include indicator values and case details. Confirm the retention settings for your edition and whether log streaming to your SIEM is available, because n8n's pricing page lists log streaming only in the Business and Enterprise plans. Test that a failed MISP or TheHive call is visible to the team that owns the workflow.
How to test enrichment and case creation before analysts rely on them
Analysts should not rely on enrichment or case creation until a documented test run has shown that the n8n workflows behave correctly against known inputs. Run the tests against a non-production MISP event and a separate TheHive organization, so test attributes, tags, cases and alerts never reach live investigations. Choose indicators whose benign status you already know, such as addresses from a documentation range, a domain you control, or the hash of a harmless test file. Before each run, record the expected enrichment result and the expected case outcome for every indicator, so the comparison runs against a fixed baseline.
Start with enrichment accuracy and duplicate handling. Compare what the MISP lookup and any other enrichment nodes return with the recorded expectation, field by field, and confirm that the workflow passes the fields analysts depend on into the case. Then submit the same indicator twice and confirm that the workflow reuses or links the existing TheHive case rather than opening a second one. Check the MISP side as well: attributes written back to the test event should carry the intended distribution level and tags, and the test event should not synchronize to any other instance. Ask the analyst lead to review a sample of the resulting cases, because a field that is present but mapped to the wrong place is easy to miss in a log.
Next, break the workflow on purpose. Revoke or mistype the API key on a test credential, point an enrichment node at an unreachable host, lower the timeout, and return a malformed response from a mock service. For each case, confirm that n8n shows the failed node, that the error branch runs, and that the case is marked as incomplete enrichment so an analyst does not read partial data as a clean result. Test notification delivery separately from the workflow status. A node that reports success does not prove that the message reached the analyst channel or the on-call route, so confirm arrival at each destination and record the time it took, which will matter during an incident.
Volume review needs one fact about n8n that is easy to misread. n8n counts an execution as one run of a whole workflow, regardless of how many steps it contains. An indicator that passes through a five-step workflow is one execution, not five. Ask the analyst lead to set the expected number of executions for each test batch and compare that with the execution list in n8n, so the team learns how many runs a typical indicator batch produces. Before you assume a plan or environment can carry production volume, check the current n8n pricing page and confirm with n8n which limits apply to your edition and deployment, because the figures change over time.
Finish with a written sign-off by the analyst lead before any production indicator flows through the workflow. The record should list each test case, the expected and actual result, any defect and its retest, the MISP and TheHive versions tested, and the n8n version and workflow export used. Store that record with the exported workflow under version control. Repeat the relevant tests after any change to nodes, credentials, mappings or platform upgrades. When production indicators start, begin with a limited feed, watch execution errors and notification delivery closely, and keep the sign-off owner responsible for approving any expansion.
Common failures in n8n MISP and TheHive workflows and their fixes
This table lists failures that appear in n8n workflows calling MISP and TheHive, with the likely cause, the check to run and the fix for each. Read it in workflow order: credentials and transport first, then data handling. Most failures trace to keys, certificates, encryption keys or sharing settings, and each has a quick test you can run before you change the workflow.
| Failure | Likely cause | Check to run | Fix |
|---|---|---|---|
| Expired or over-scoped API keys | The MISP or TheHive key has expired, or it belongs to a user with broader roles than the workflow needs | Call both APIs with the stored key from a test workflow, then review key expiry and the owning user's role | Create a dedicated service account with minimum roles, set an expiry, rotate the key and update the n8n credential |
| MISP instance on end-of-life 2.4 | The instance was installed on MISP 2.4, which receives security fixes only | Check the version in the MISP administration interface and compare it with the project's current supported release | Plan an upgrade to MISP 2.5 using the project's upgrade script on Ubuntu, and test node operations on a copy first |
| TLS trust errors between n8n and either platform | The platform presents a certificate from an internal or self-signed CA that the n8n runtime does not trust | Request the platform URL from inside the n8n container or worker and read the exact certificate error | Add the internal CA to the trust path that n8n uses and confirm the certificate name matches the URL; avoid disabling verification |
| Duplicate cases from retried executions | A retried or redelivered trigger reaches the case-creation step before any existence check runs | Compare execution history for repeated trigger IDs and look for cases sharing the same source reference | Search TheHive for an existing case using a stable reference, such as the MISP event UUID, before creating a new one |
| Credentials fail on queue-mode workers | The encryption key on a worker or webhook processor differs from the main instance, so stored credentials cannot be decrypted | Compare the encryption key setting on the main instance with every worker and webhook processor | Restore the original key from your secrets store on every node, restart them, then rerun a test execution on a worker |
| Enrichment results ignore distribution settings | The API key's organization or role cannot see events or attributes shared at a restricted distribution level | Run the same indicator query with this key and with a user in the intended sharing group, then compare results | Use a key whose organization belongs to the intended sharing group and document which results the workflow can see |
When a dedicated SOAR such as Shuffle fits better than n8n
n8n fits when a playbook is a short chain of lookups and notifications. A typical flow takes an indicator, queries MISP or TheHive through their nodes, applies a scoring step and posts a summary to an analyst channel. The canvas makes these flows easy to review, and each run counts as one execution of the whole workflow regardless of step count, which keeps the usage model simple.
Check these points against your use:
- The Community edition is free to self-host, but the Sustainable Use License limits use to your internal business purposes, so confirm your deployment fits those terms.
- SSO and LDAP, environments with Git, and log streaming are included only on the Business and Enterprise plans.
- Multi-main high availability is restricted to Enterprise self-hosted deployments.
- Queue mode needs Redis, PostgreSQL and a shared encryption key across workers, so plan key custody before the first worker starts.
- Long branching playbooks with many app actions become harder to maintain as the canvas grows.
Before committing, confirm that your enrichment flows stay short and that your license and plan cover your hosting model.
Shuffle separates the management server from the execution runtime, and that split decides how you size and operate it. The server side holds a frontend, a Go backend API on port 5001 and an OpenSearch document database. Orborus runs on the runtime side, polls the backend for jobs and starts a worker for each workflow execution, and that worker starts the app containers.
Key points for planning:
- Shuffle documents four deployment models: a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, and Kubernetes with Helm charts.
- The hybrid model needs no inbound firewall ports for the local Orborus, which can matter for analyst networks with strict ingress rules.
- For high availability, the docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when several backends run, and more than one Orborus node.
- Backend and frontend scale across all servers in that model, so capacity planning covers OpenSearch and NFS as well as the containers.
- Losing or changing SHUFFLE_ENCRYPTION_MODIFIER breaks every saved app authentication, so it belongs in your backup and key custody plan.
Before choosing this model, confirm that your team can operate an OpenSearch cluster and shared storage over the long term.
Shuffle's app model, identity options and pricing metric shape how the platform grows. Apps are built from OpenAPI specifications in the App Creator or written in Python with the Shuffle app SDK, and they run as versioned Docker containers. Integrations therefore become versioned artifacts you can review and roll back, managed much like other container images.
Points to weigh:
- SAML single sign-on arrived in version 0.9.16 and OpenID Connect in 1.0.0, both available on-premises and in the cloud, with per-tenant SSO enforcement.
- Shuffle Cloud is deprecating SAML in favor of OpenID Connect, so plan your identity integration around OIDC if you use the cloud.
- Shuffle states that all features are in the open-source edition, while paid tiers differ in feature limits, scaling and support. Those limits have been actively enforced since v2.1.1.
- Licensing uses one metric, app runs, which counts actions that execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited.
- Step count drives the Shuffle quote, while n8n counts a whole workflow as one execution.
Before you decide, ask Shuffle to model app-run volume against your expected alert and playbook load, and confirm which limits your chosen edition enforces.
The choice usually comes down to three questions: how complex the playbooks are, how much case management analysts need, and who will run the platform after go-live. Use these as a checklist, and test both platforms against your three most common playbooks before you commit.
What to examine for each question:
- Playbook complexity: short enrichment and notification chains suit n8n well, while branching playbooks, many app actions or per-execution isolation point toward Shuffle.
- Case management: confirm which case views, assignment and handoff features each platform gives analysts in your own tests, and how each one writes records to TheHive.
- Staffing: Shuffle adds an OpenSearch cluster and Orborus nodes to operate, while n8n in queue mode adds Redis, PostgreSQL and a worker pool.
- Licensing: the Sustainable Use License and the AGPL-3.0 carry different obligations, so have counsel review how each fits your hosting and distribution.
- Support: n8n Enterprise includes dedicated support with an SLA, so ask Shuffle which support tier your team would need.
Run a pilot with your three most common playbooks on both platforms, and record the staff hours and run volume you observe.
Questions buyers ask before hiring help with n8n security automation
What drives the cost of n8n MISP and TheHive security automation?
The main drivers are how many indicator sources feed the workflows, whether each system has a usable native node or needs HTTP calls that someone must build and maintain, how deeply fields are mapped between MISP events and TheHive cases, how much testing runs against both platforms, and what production hardening is required.
One-time work covers workflow design, node or HTTP client build, field mapping, test cases and hardening. Recurring work covers keeping the workflows working after n8n, MISP or TheHive upgrades and handling API changes. Ask any quote to list each indicator source, each mapping and each test environment separately so you can see which items move the number up or down.
Does n8n include native MISP and TheHive nodes for these workflows?
Confirm this against the node documentation for the n8n version you run before you plan the build, because node coverage changes between releases and the operations you need may not be included. If a native node covers the calls, the build is simpler and upgrades are easier to track.
If a node does not cover them, the team builds HTTP Request calls against each platform's API. That means someone owns authentication, pagination, error handling and version checks. n8n ships minor releases roughly weekly under semantic versioning, so recheck the node set at every upgrade. Your quote should state which operations use native nodes and which use HTTP calls.
Can our SOC build MISP and TheHive automation in n8n on its own?
Often yes for a small set of enrichment lookups, and it is harder for multi-source correlation, case mapping and production operation. A capable SOC team with n8n experience can build simple flows, but the work that usually fails is the unglamorous part: error paths, retries, credential handling, idempotent case creation and tests against both platforms with representative sample data.
Ask internally who will own the workflows after go-live, who reviews changes and who responds when an enrichment step fails. If those owners exist and have the time, build in-house. If they do not, a scoped engagement can cover the build while your team learns to run it.
How is a fixed-scope engagement agreed and how long does it take?
Most DeployOpen engagements are fixed-scope, which means the scope, deliverables and timeline are agreed in writing before work starts. The scope should name the indicator sources, the workflows, the MISP and TheHive versions and environments, the test approach and the hardening items.
Duration depends on those choices and on how quickly your team provides access and decisions, so no single timeline applies across engagements. Ask for the milestones, the acceptance criteria and the changes that would reopen the scope. Support, upgrades and continuous testing are available as retainers after handover.
What must our team provide before a security automation build starts?
Plan for named owners and access before the first workflow is built. You will need API accounts with the scopes the workflows require in MISP and TheHive, ideally separate service accounts for test and production, plus access to the n8n instance or a test copy of it.
Test data matters. Provide sample events, indicators and cases that reflect your alert types, and agree which data may leave your environment. Name a technical owner, a SOC owner who approves case and notification logic, and a sign-off owner for production release. Late sign-off is a common cause of schedule slippage, so confirm these names in writing at kickoff.
Does DeployOpen publish a price list for n8n security automation?
No. DeployOpen does not publish a price list. A quote follows from the written scope, so the fastest route to a number is a scope document that lists indicator sources, workflows, native versus HTTP operations, mapping depth, test environments and hardening items.
Ask each quote to separate one-time build work from recurring support, upgrades and testing retainers, and to state the assumptions about your access and sign-off. Compare quotes by checking that each one covers the same scope document, line by line.
Does n8n licensing affect running SOC automation on our own servers?
Internal business use generally falls within n8n's Sustainable Use License, which permits use or modification for your own internal business purposes. Confirm this with your legal and procurement teams before you rely on it.
Check three points. Files with .ee in their name or directory require a valid n8n Enterprise License. Distribution is limited to free, non-commercial use, so the license does not cover selling workflow packages to customers. On n8n's pricing page, SSO, LDAP, Git environments and log streaming are listed for the Business and Enterprise plans, and multi-main high availability is limited to Enterprise self-hosted deployments.
How DeployOpen scopes and delivers n8n security automation
DeployOpen plans n8n security automation around your own MISP and TheHive instances, inside infrastructure you control. Each engagement starts with a written scope that sets which enrichment, case and notification workflows are included, how credentials are held, and how the n8n license terms apply to your use.
How we scope
- Inventory the MISP and TheHive instances, versions and API access the workflows will call
- Agree in writing which indicator enrichment, case creation and analyst notification flows are in scope
- Confirm n8n edition, license fit under the Sustainable Use License and whether queue mode is needed
How we build
- Build enrichment and case workflows with the n8n MISP and TheHive nodes, with credentials held in n8n
- Plan the encryption key sharing and worker layout if queue mode is used for the workflows
- Test each workflow against sample indicators and non-production MISP and TheHive data before go-live
How we hand over
- Document each workflow's triggers, inputs, outputs, credentials and failure behavior
- Provide runbooks for credential rotation, encryption key handling and restoring the n8n database
- Walk through the workflows with the analysts and administrators who will operate them
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover
- Plan n8n and node upgrades against release notes and test workflows before rollout
- Review workflow changes as MISP and TheHive APIs evolve, under the agreed support scope
