Should you self-host Graylog or buy Graylog Cloud?
Choose Graylog Cloud when fixed vendor defaults and vendor-run operations fit your requirements. Choose self-managed Graylog when data location, LDAP or Active Directory, Okta or OIDC login, custom plugins, the outputs framework, custom index rotation or server file and SSH access are requirements rather than preferences. The decision turns on which of those features your team needs and on who will carry uptime for the log pipeline, because Graylog's own comparison places LDAP, OIDC, outputs, plugins and server access in self-managed deployments only. Graylog Cloud does support SAML SSO configured by the Cloud team, so confirm whether SAML alone meets your identity requirement before you rule Cloud out.
Graylog Cloud has real operational strengths. Graylog maintains the instance, provisions it after the license purchase and includes 24x7 operations support and managed SMTP, which self-managed customers do not get by default. The default contract shape is 90 days of live data and 1 year of retention, with archived data included at no extra cost and optional archiving to a customer S3 bucket. Ask Graylog how live storage is sized from your contracted daily ingest volume, and whether the 300-second search timeout and the restriction on third-party plugins fit your investigations. If your residency or audit requirements place log data in a specific region or on your own infrastructure, that is a decision you should settle first, since Cloud's defaults do not let you choose the storage location of your logs.
If you self-host, budget for the work Graylog Cloud removes. Your team owns the Graylog server nodes, the MongoDB configuration store (7.x through 8.2.x for Graylog 7.2), the search backend (Graylog Data Node is the documented recommendation, with self-managed OpenSearch 1.1.x through 3.7.x as the alternative) and the uptime of each. Graylog's multi-node guide recommends three Graylog and MongoDB nodes, three Data Nodes and a load balancer for medium to large deployments. Ask your team to name who gets paged at 2 a.m., who handles upgrades and how the licensing cost compares with the staffing cost of running that stack. Note that Graylog Open is free, but Graylog Enterprise and Graylog Security are paid editions, and archiving, correlation and prebuilt detection content sit behind them, so confirm which features your self-managed design needs before comparing totals.
How Graylog Cloud and self-managed Graylog compare on each factor
This table compares Graylog Cloud, which Graylog runs for you, with Graylog licensed for your own servers, row by row on licensing, retention, data location, authentication, plugins, ingest and who carries uptime. Read each row against your own requirements, because the answer that matters often depends on one control your auditors or security team need. Enterprise and Security pricing applies to both models according to the Graylog pricing page, so the edition decision is separate from the hosting decision.
| Factor | Graylog Cloud | Self-managed Graylog |
|---|---|---|
| Licensing and cost structure | Graylog-maintained subscription, sold directly or on AWS Marketplace; Enterprise or Security pricing applies per the pricing page | Lower licensing cost per the pricing page; you pay for servers, storage, staff and Enterprise or Security editions if needed |
| Default live and archive retention | 90 days live and 1 year archive, set in the contract | Retention is set by you through index rotation and archive settings |
| Data location | Hosted by Graylog; confirm the region and tenancy in writing before signing | Stored wherever you deploy, including your own data centers or air-gapped networks |
| Authentication | SAML SSO configured by the Cloud team; LDAP, Active Directory, Okta and OIDC are not offered | LDAP, Active Directory, Okta and OIDC login are available |
| Outputs and notifications | Outputs framework and script notifications are not offered | Outputs framework and script notifications are available |
| Custom plugins | Third-party plugins are not supported for security reasons | Custom plugins can be installed on your servers |
| Index rotation and server access | Custom index rotation and server file or SSH access are not offered | Custom index rotation and server file or SSH access are available |
| Data ingest paths | Graylog Forwarder or specific pull-based inputs only | Full range of inputs you configure, such as syslog, GELF and Beats |
| Search timeout | Fixed 300 seconds per query | Set by your own server configuration |
| Preinstalled content and GeoIP | Illuminate content and GeoIP through IPinfo included; 24x7 operations support and managed SMTP included | Not included by default; you source, license and maintain content and mail relay |
| Who provides uptime | Graylog operates the instance and its uptime | Your team owns infrastructure, MongoDB, search backend, patching and availability |
What data location and access control mean for compliance
For a regulated team, the question is less which product is more secure and more who controls the evidence. Data location, retention, access paths and identity integration decide which controls you own and which you must verify with the vendor. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, so confirm the control mapping with your auditor and Graylog before you commit.
Where the log data lives
In self-managed Graylog, logs stay in the storage you choose, whether that is your cloud account, data center or air-gapped network. In Graylog Cloud, Graylog provisions and runs the instance, so you must establish the region, tenancy and subprocessors in writing. Ask the vendor where live indices, archives and backups physically reside before you map any data residency requirement.
Who sets retention
Cloud defaults to 90 days of live data and 1 year of retention, both set in the contract. Self-managed customers set retention through index rotation and retention rules, and they decide when deletion happens. If an assessor expects a fixed retention period, write that period into the contract for Cloud or into your own retention procedure for self-managed.
Server file and SSH access
Server file and SSH access is available only in self-managed Graylog. That access lets your team inspect configuration, collect local evidence and apply hardening directly, but it also places host administration inside your access review scope. In Cloud, ask Graylog which administrative actions are performed by its staff, how those actions are logged and how you would receive those logs.
Identity integration and login controls
LDAP and Active Directory integration, Okta and OIDC login are listed as self-managed features, while Cloud supports SAML SSO configured by the Cloud team. Map each login method to your identity provider policy, including MFA, joiner and leaver processes and privileged roles. Confirm with Graylog whether the SAML setup meets your session and role mapping requirements before you rely on it.
Archive location and export
In Cloud, archiving includes 1 year of archived data at no extra cost, and Graylog can archive to a customer S3 bucket on request. Self-managed archives sit wherever your storage is configured. Decide where archived evidence must reside, who holds the bucket keys and how you would prove deletion at end of retention before you agree on the archive design.
Control ownership and audit evidence
Self-managed deployments put patching, backup, access reviews and hardening on your team, and DeployOpen can prepare those controls and evidence within a written scope. Cloud shifts operational controls to Graylog, so ask for its current security documentation and the controls it covers. Confirm with your auditor and the vendor which control gaps remain before you finalize the design.
How Graylog Cloud provisions and sizes your instance
Graylog provisions your Cloud instance after the license purchase, and the contract sets the size. Live storage is sized for up to 90 days of retention based on the daily ingest volume written into the contract, and the docs state that 1 year of archived data is included at no extra cost. Archives can be written to your own S3 bucket on request. Before signing, confirm the daily ingest figure you are contracting for, how much of it is peak versus average, and whether a later increase in volume triggers a resize and a new price. Those two numbers determine how much searchable history you get, so they belong in the written scope, not in a footnote.
Data arrival is the first constraint to test. In Graylog Cloud, logs reach the instance through the Graylog Forwarder or specific pull-based inputs, and third-party plugins are not supported for security reasons. Self-managed Graylog accepts the broader input set and custom plugins described elsewhere on this page, so map every source you run today (syslog, GELF, Beats, cloud APIs, appliances) to a Forwarder or pull input before you commit. Any source that needs a custom input or a plugin is a reason to stay self-managed or to add a forwarding step you must build and operate.
Search timeouts are fixed at 300 seconds, so test your heaviest queries before you rely on them. Long historical searches, wide regular expressions and dashboards that scan months of data are the usual candidates. Run your top queries against a realistic time range in a trial or proof of concept and record how long they take. If any routinely approach the limit, plan the investigation workflow around narrower time windows, saved searches or archive restores, and confirm with Graylog how archived data is brought back for searching. Self-managed deployments do not share this fixed ceiling, but they take on the tuning work instead.
What your team runs in each hosting model
This table compares who operates each Graylog layer under Graylog Cloud and under self-managed Graylog, from MongoDB and the search backend to server nodes, patching, backups and monitoring. Read each row as a question to answer for your own environment before you choose a hosting model.
| Operating area | Graylog Cloud | Self-managed Graylog |
|---|---|---|
| MongoDB (configuration and metadata) | Operated by Graylog as part of the managed instance | Your team installs, runs and upgrades MongoDB 7.x to 8.2.x as a replica set |
| Search backend (Data Node or OpenSearch) | Operated by Graylog; live and archive storage is provisioned from the contract | Your team runs Graylog Data Node or self-managed OpenSearch 1.1.x to 3.7.x, including certificates and cluster membership |
| Graylog server nodes | Provisioned and maintained by Graylog after license purchase | Your team deploys nodes, sets is_leader to false on followers and places a load balancer in front |
| Patching and upgrades | Performed by Graylog's Cloud team | Your team schedules and tests every component, including the search backend version |
| Backups and archive storage | Archive included for one year; archiving to a customer S3 bucket available on request | Your team designs and tests backup and index retention on infrastructure you control |
| Uptime and incident response | 24x7 operations support included | Your team owns uptime, on-call coverage and recovery; confirm any vendor support tier separately |
| Monitoring and capacity | Live storage sized from contracted daily ingest for up to 90 days | Your team sizes storage (daily ingest times retention days times 120 percent) and monitors the message journal |
| Infrastructure footprint | Hosted by Graylog; you do not supply the servers | Three Graylog and MongoDB nodes, three Data Nodes and a load balancer are the recommended layout for medium to large scale |
Moving between Graylog Cloud and self-managed Graylog
This sequence shows how a team would move its inputs, stream and pipeline logic, alerting, retention and identity setup from one Graylog deployment model to the other, and what must be confirmed before cutover.
Confirm the vendor-side constraints first
Before any design work, ask Graylog in writing which Cloud settings can be changed, what the contract's daily ingest volume and retention terms are, and whether a self-managed license tier covers the features you need. Confirm whether your current Cloud instance can export configuration or whether you must rebuild it by hand. The output is a written list of what can be moved, what must be rebuilt and what Graylog will not provide, which becomes the basis for the migration scope.
Inventory inputs and re-point data sources
List every source sending logs today. Cloud accepts data through the Graylog Forwarder or specific pull-based inputs, so sources built around those paths need new targets when moving to self-managed servers, and sources sending syslog, GELF or Beats directly may need firewall and certificate changes in the reverse direction. Confirm with Graylog which Cloud inputs can be exported. The output is an inventory mapping each source to its old and new destination, plus a test plan that sends sample events through each path.
Rebuild streams, pipelines and event definitions
Recreate streams, processing pipelines and event definitions on the target instance, because routing and alerting logic must be re-entered or rebuilt from exported configuration, depending on what Graylog confirms is portable. Check each alert's notification target, including PagerDuty, Slack and email, and confirm that managed SMTP on Cloud has an equivalent mail relay on your own servers. The output is a side-by-side record showing that each rule fires on the same test events in both environments.
Reconcile retention and index rotation settings
Map the Cloud default of 90 days of live data and one year of retention to the retention rules you choose on self-managed servers, where you control index rotation by message count, size or time and decide how old indices are deleted. Size storage with the daily ingest times retention days times 120 percent guidance in the system architecture documentation. The output is a retention table per stream that states the live period, archive period and the owner who approved each value.
Recreate identity and access integrations
Cloud supports SAML SSO configured by the Cloud team, while LDAP or Active Directory, Okta or OIDC login, and server-side settings are available only in self-managed Graylog. When moving toward self-managed, configure those integrations on your own servers and test role mapping for every user group. When moving toward Cloud, confirm which of these features you will lose and document the replacement access path. The output is a tested login matrix covering each user group and each authentication method.
Validate archive access in the customer S3 bucket
Cloud includes one year of archived data and can archive to a customer S3 bucket on request, so confirm with Graylog the bucket ownership, access policy, encryption settings and the path Graylog uses to write and restore archives. Restore a sample archive and search it to prove the data is readable after the move. The output is a signed-off restore test and a documented bucket policy that your security team has reviewed.
Cut over and confirm the old environment
Switch sources to the new destination in a planned window, run both environments in parallel for a period agreed in your written scope, and compare alert volumes and search results. Keep the previous instance read-only until retention and archive checks pass. The output is a cutover record listing each source switched, each alert verified and the date the old instance was retired, approved by the system owner.
Assign operations and support ownership
Cloud includes 24x7 operations support, managed SMTP, preinstalled Illuminate content and GeoIP through IPinfo, while self-managed deployments do not get these by default. Name who will patch, back up, monitor uptime and maintain the search backend after cutover, and confirm which of those responsibilities DeployOpen would take on under a written, fixed scope. DeployOpen plans and executes a migration only under that agreed scope. The output is a responsibility matrix signed by both your team and the implementation partner.
What Graylog pricing covers and what it leaves out
The Graylog pricing page draws the line between licensing and operations, and your quote has to follow the same line. Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, and both are licensed on processed data with no per-user or per-device fees. The same page describes self-managed Graylog as the lower licensing cost option, with the customer providing infrastructure and uptime. Graylog Cloud is maintained by Graylog and is also sold on AWS Marketplace, so the purchase route can differ from the contract route.
In self-managed deployments you pay for the license (if you buy a paid edition), plus the servers, storage, MongoDB and search backend, backups, patching, on-call coverage and the staff hours to run them. Those costs recur and scale with ingest volume and retention, so a low license line can sit beside a large infrastructure budget. In Cloud, the subscription bundles hosting, operations and the default live and archive retention, but the price moves with the contract's daily ingest volume and retention terms. Ask the vendor for a written quote that states the daily ingest volume assumed, the live retention period, the archive allowance and whether the figure is per processed GB or per Compute Unit, and check that the minimum applies to your real volume.
Before you compare totals, confirm what is excluded from each figure: taxes, add-on modules, support tiers beyond the stated editions, data egress for archive restores and any migration work. Ask the vendor to show how the quote changes if your ingest grows, and whether a self-managed purchase would still need the paid Enterprise or Security features that your use case depends on. Two-year totals, not year-one license costs, are the fair basis for this decision.
Questions buyers ask before choosing Graylog Cloud or self-managed
Is self-managed Graylog cheaper than Graylog Cloud?
Graylog's pricing page says self-managed Graylog has a lower licensing cost, but the license is only one line in the total. Graylog Open is free with no volume limits, while Enterprise starts at 15,000 US dollars per year and Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Paid editions are licensed on processed data with no per-user or per-device fees. Self-managed costs recur for servers, storage, MongoDB, the search backend, backups and the staff who run them. Storage grows with daily ingest times retention days times 120 percent, so retention length is the largest cost driver. Ask Graylog for a written quote that covers the license, Cloud sizing for your daily ingest, and included archive, then compare it with your own infrastructure and staff hours. Graylog pricing
How long does it take to move from Graylog Cloud to self-managed?
No supplied source gives a migration duration, so confirm the timeline in writing before you commit. The duration depends on how much data you keep, how many inputs and forwarders you must repoint, how many streams, pipelines and event definitions you must rebuild, and whether archived data has to move. Cloud receives data through the Graylog Forwarder or specific pull-based inputs, and Cloud includes preinstalled Illuminate content and GeoIP through IPinfo, which self-managed deployments do not get by default. Those items need a plan of their own. Ask Graylog and any implementation partner for a fixed-scope plan that lists each input, pipeline, alert and archive location, along with cutover and rollback steps. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
What does a self-managed Graylog team have to own?
Self-managed Graylog moves infrastructure and uptime work to your team. Graylog's pricing page says the customer provides both. In practice, plan to own:
- Servers or cloud instances for Graylog nodes, MongoDB for configuration and metadata, and the log storage backend
- The search backend, either Graylog Data Node, which Graylog recommends, or a self-managed OpenSearch cluster within the supported version range
- Upgrades, patching and version alignment across Graylog, MongoDB and the search backend
- A multi-node layout if you need one, which Graylog's guide describes as three Graylog and MongoDB nodes, three Data Nodes and a load balancer
- Backups, retention settings, monitoring and on-call coverage, which Cloud includes as 24x7 operations support
Ask which of these you could hand to a partner under an ongoing retainer.
Can a small team run self-managed Graylog without outside help?
Yes, if your team already has the skills for the stack, but no supplied fact measures how many hours that takes. Graylog installs from Debian or RPM packages or with Docker Compose. Medium and large deployments add MongoDB replica sets, a Data Node cluster, leader settings on follower nodes and a load balancer. Journal sizing guidance calls for 3 to 5 times daily ingest on SSDs. Paid features such as archive restore, correlation and data tiering need a Graylog Enterprise or Security license. Outside help is one option. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure, under fixed-scope engagements with optional retainers. Before you decide, have your engineers name the owner for each layer and the on-call rota that covers it.
Can Graylog Cloud archive to our own S3 bucket?
Yes, on request. Graylog's Cloud documentation says Cloud includes one year of archived data at no extra cost and can archive to a customer S3 bucket on request. Live storage is sized for up to 90 days of retention based on the contract's daily ingest volume, and the retention period is set in the contract. Confirm with Graylog who owns the bucket, its region, the access policy, the archive format and how restores work. Also confirm whether archives can be restored into Cloud or into a self-managed instance, and at what cost, since archive restore is a paid Enterprise feature on self-managed Graylog. Check your data residency and retention obligations as well, because self-managed Graylog gives full control over data location and retention.
Which LDAP, OIDC and plugin features do we lose on Graylog Cloud?
Graylog's Cloud feature comparison lists these as available only in self-managed Graylog: LDAP and Active Directory integration, Okta and OIDC login, script notifications, the outputs framework, custom plugins, custom index rotation, and server file or SSH access. Cloud supports SAML single sign-on, which the Cloud team sets up. Cloud also does not support third-party plugins, for security reasons. If your directory is Active Directory or your identity provider uses OIDC, confirm that SAML meets your login model before you choose Cloud. Also check whether alerting depends on script notifications or outputs, and whether you need custom index rotation. Confirm the exact authentication setup with Graylog and your identity team before you rely on it.
Which Graylog version should we plan for?
Plan for the Graylog 7.2 line. Graylog's changelog and tags show 7.2.0 tagged on October 12, 2026, and the current documentation covers version 7.2. Confirm the exact patch release with Graylog before you build, because patch levels change. Check the compatibility matrix for the MongoDB and search backend versions your release supports. For Graylog 7.0 to 7.2, that means MongoDB 7.x up to 8.2.x and OpenSearch 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. Graylog has deprecated OpenSearch 1.x since 7.0 and will remove it in Graylog 8.0, so avoid building new clusters on that line. Graylog recommends Data Node as the search backend. Ask Graylog for the support window of each release line before you commit.
When self-managed Graylog is the right call
Choose self-managed Graylog when a requirement is one Graylog Cloud does not offer. According to Graylog's feature comparison, LDAP and Active Directory integration, Okta and OIDC login, script notifications, the outputs framework, custom plugins, custom index rotation and server file or SSH access are available only in self-managed Graylog. If your identity team needs LDAP or AD group mapping, or your SOC forwards alerts through the outputs framework, those needs decide the question before price does. The same applies to a data location rule: self-managed Graylog gives you full control over where data lives and how long it is kept, while Cloud sets live retention to 90 days and one year of archive by default in the contract. Confirm with Graylog whether a non-default archive or residency arrangement is possible before you assume Cloud can meet it.
Self-managed Graylog also fits teams that want to own the platform's operating surface. Custom index rotation, plugin development and direct server access let engineers tune storage and pipelines in ways Cloud does not allow. Expect the trade. You take on the infrastructure, the MongoDB and search backend upkeep, and the uptime work, including the multi-node layout Graylog recommends for medium to large deployments. Ask your team who will own patching, backups and capacity before you commit, and whether that person is funded for it.
Cloud remains the better default for teams without platform staff or with simple, steady ingest. Graylog Cloud includes 24x7 operations support, managed SMTP, preinstalled Illuminate content and GeoIP through IPinfo, none of which self-managed deployments get by default. If you need none of the self-only features above, the operating work you avoid may outweigh the licensing difference. Test that claim against your own ingest profile and staffing before deciding. Graylog's pricing page is the next read for licensing terms, and a written scope from a provider should show which self-hosted features you actually need.
How DeployOpen scopes and runs self-managed Graylog
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Graylog, that means working out whether a self-managed deployment is the right fit before any servers are built, then carrying it through to a documented, supported handover.
How we scope
- Written scope that states which Graylog edition, storage backend and retention targets the deployment will use
- Inventory of LDAP, OIDC, outputs, plugins and server access requirements that Cloud does not offer
- Daily ingest volume and retention periods agreed up front, so storage and journal sizing are documented
- Named deliverables and milestones agreed in writing before any work starts
How we build
- Graylog server, MongoDB and search backend installed in your cloud, data center or air-gapped network
- Identity integration configured against your directory or OIDC provider and tested with real accounts
- Inputs, streams, processing pipelines and index rotation configured to match the agreed retention plan
- Hardening, backup and restore checks run and recorded before the environment is accepted
How we hand over
- Runbooks covering node operations, index retention, upgrades and MongoDB and search backend maintenance
- Configuration and architecture documentation kept with the deployment so your team can audit it
- Walkthrough sessions for administrators on alerting, event definitions and notification routing
- Clear record of what remains with your team, including uptime and on-call responsibilities
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Upgrade planning that checks Graylog and search backend version compatibility before each change
- Security testing of the deployed platform on request, scoped in writing like any other engagement
- Confirm in your quote what is covered for uptime, response times and 24x7 coverage before signing
