Elastic Agent Fleet-managed vs standalone: which model fits your estate
Your decision is how each Elastic Agent gets its configuration and its upgrades. Fleet management is Elastic's recommended model, and Elastic describes standalone mode as reserved for advanced users, so the default answer for most estates is to enroll agents in Fleet through Kibana. In Fleet, agents are defined, configured and managed centrally, and policy changes reach the hosts from one place. In standalone mode, each host carries its own local configuration, and your team owns every change and every upgrade on every host. Elastic Security is the same product in both cases: the detection engine, Timeline, Cases and Elastic Defend behave identically, so the choice concerns operations, not features.
Standalone is the right call under specific conditions. The first is connectivity: if hosts cannot reach Kibana or a Fleet Server, for example in a locked-down or air-gapped segment, central management is not available to them. The second is ownership: if your organization already manages configuration through its own tooling and change control, a second control plane in Fleet may duplicate that work. Before you commit, confirm with Elastic which Fleet Server and network paths your topology needs, and map every host against those conditions. Hosts that fall outside Fleet still need a documented upgrade and policy-change process, because nothing will prompt you when a local configuration drifts.
Plan for the recurring work either way. Under Fleet, the recurring effort is mostly policy design and staged rollout; under standalone, it is per-host configuration management and version tracking across the whole fleet. Ask your Elastic partner or support contact to state, in writing, which agent versions and policy settings you will maintain in each model, and who performs each upgrade. For the operational detail, read the Elastic documentation on installing Elastic Agents before you decide.
How the two agent models compare on the factors that matter
This table sets Fleet-managed and standalone Elastic Agent side by side on configuration, policy delivery, upgrades, central infrastructure, locked-down hosts and owner effort. Read each row as a question to answer for your own estate, and confirm version-specific behavior in the Elastic documentation for the release and integrations you run.
| Factor | Fleet-managed agent | Standalone agent |
|---|---|---|
| Where configuration lives | Policies are defined centrally in Fleet in Kibana and assigned to agents | Configuration is written locally on each host and maintained by the owner |
| How policy changes reach hosts | Fleet pushes updated policies to enrolled agents, subject to agent check-in | Changes require editing each host's configuration and restarting or reloading the agent |
| How upgrades happen | Upgrades are driven from Fleet, which Elastic describes as considerably easier to manage | The owner upgrades each agent package and reconciles configuration on every host |
| Central infrastructure required | Kibana and Fleet Server must run and stay compatible with the agent version | No Fleet Server dependency, though the Elastic Stack receiving data must still run |
| Fit for air-gapped or locked-down hosts | Works where agents can reach Fleet Server, so outbound paths and certificates need planning | Often suits hosts that cannot reach Fleet, but local change control becomes the owner's job |
| Elastic's guidance | Elastic recommends Fleet management for agent management and upgrades | Elastic describes standalone mode as reserved for advanced users |
| Effort the owner carries | Fleet server hosting, enrollment and policy design; confirm component requirements per version | Per-host configuration, version tracking and manual upgrades across the fleet |
| Confirm in the documentation | Supported Fleet Server versions, enrollment tokens and integration policy support for your release | Supported integrations, configuration keys and upgrade paths for the agent version you deploy |
What each model adds to the architecture
Both models feed the same Elasticsearch cluster, but they differ in what sits between the host and that cluster. Fleet-managed deployments add Kibana-hosted policy management and, depending on your design, Fleet Server; standalone deployments move that control into files on each host. Read each card with the question of who patches, backs up and troubleshoots that part.
Kibana with Fleet
Fleet runs inside Kibana and is where integration policies, agent enrollment and agent upgrades are defined for Fleet-managed agents. Your team must patch and back up the Kibana instance and its saved objects, and must keep Kibana on a version that matches the Elastic Stack you run. Only the Fleet-managed model uses this layer. Confirm the Kibana and Fleet compatibility rules for your target version in Elastic's documentation before you plan an upgrade.
Fleet Server placement and sizing
Fleet Server is the component that Fleet-managed agents connect to for enrollment and policy delivery, and it needs its own host, network path and certificates. Placement determines which network zones can reach it and how agents behave when a zone is isolated. Sizing and placement must be confirmed with Elastic's documentation for your version, since they change with agent count and release. Only the Fleet-managed model needs Fleet Server.
Elastic Agent binary and policies
Elastic Agent is one binary per host that runs the integrations you enable, and Elastic Defend is the endpoint protection integration that runs under it. In both models the host carries the same agent package, so you patch the binary on every host. Confirm which integrations and Elastic Defend features your license tier allows before you enable them on production endpoints.
Local configuration files on standalone hosts
In standalone mode, the agent reads its configuration from local files on each host, and changes to integrations, outputs and certificates are made by editing those files or pushing them with your own tooling. Your team owns version control, backups and rollback for every host. This layer exists only in the standalone model. Elastic reserves this mode for advanced users, so confirm that your staff can operate it before you choose it.
Elasticsearch cluster both models feed
Both models send events to the same Elasticsearch cluster, so the cluster, its index lifecycle settings, its storage and its certificates are a shared responsibility regardless of how agents are managed. Confirm the output settings and index templates your agents use for your version, and back up cluster state and snapshots on a schedule you can restore from. Management model does not remove any cluster duty.
Which model suits each kind of host and network
Where hosts can reach a central Fleet Server over the network and change is routine, the default path is Fleet management. Elastic recommends Fleet because it makes agent management and upgrades considerably easier, and standalone mode is described as reserved for advanced users. Policy changes then happen once in Kibana and reach every enrolled agent, rather than being edited on each host. The cost is a Fleet Server to size, secure and keep available, plus the Kibana access model that comes with it.
- Policy distribution: Integration settings are set in one place and applied across host groups.
- Upgrades: Agent upgrades are driven from Fleet, which reduces per-host manual work.
- Fleet Server dependency: Plan for its availability, certificates and network path before rollout.
- Standalone exceptions: Only hosts with a specific reason to be configured locally should be carved out.
- Ownership: Name who edits policies and who approves them, since Kibana access becomes a control point.
Before you commit, confirm that every host in scope can reach Fleet Server and that your team can run it as a service with the availability you require.
On air-gapped or tightly egress-filtered networks, the first question is whether an agent can reach Fleet Server at all, and along which path. Where it cannot, standalone agents with locally managed configuration may be the only option, and their owners then carry configuration and upgrade work themselves. Another possibility is a Fleet Server placed in the restricted zone with approved paths to Kibana and the cluster, which keeps Fleet management but adds a component to approve. Illustrative example: a site that permits only one outbound path through a data diode may still need a design review before anyone can assume Fleet works.
- Reachability: Map which hosts can open connections to Fleet Server and to the Elasticsearch endpoints.
- Package delivery: Confirm how integration packages and agent upgrades reach hosts without internet access.
- Manual upgrade load: Standalone agents on isolated hosts need a documented, repeatable upgrade process.
- Certificates: Decide how trust material is issued, rotated and distributed inside the enclave.
- Evidence: Keep a record of configuration changes that cannot be pushed centrally.
Before you choose, ask the network team which flows are allowed in each direction and whether your security approvals cover a new internal service.
Some hosts, such as production databases or payment-adjacent systems, have change windows and approval gates that make any agent update a formal event. Here the question is less about connectivity and more about what the change approval process allows. A centrally pushed policy change may need the same approval as a local file edit, so the operational benefit of Fleet is smaller if each change still needs a ticket and a window. Standalone mode can keep configuration fixed between approved releases, but it shifts drift control onto the host owner.
- Change scope: Establish whether a central policy change counts as a new change or a pre-approved configuration.
- Upgrade cadence: Agree which agent versions are allowed and how long each approved version stays in service.
- Drift detection: Decide how you will spot a host whose configuration no longer matches the approved baseline.
- Rollback: Document how a failed agent upgrade is reversed on a host you cannot easily touch.
- Access: Limit who can change policies, since central control concentrates risk in Kibana.
Before you choose, ask the change board what it will approve in advance, such as a standing approval for minor agent updates, and whether a centrally managed change needs the same review as a local one.
Most estates mix connected servers, isolated segments and locked-down hosts, so a single model rarely fits all of them. A common pattern is Fleet management for the connected majority and standalone agents where reachability or change control requires it, but that split creates two operating procedures and two places where configuration can diverge. Illustrative example: a team might run Fleet policies for application servers and keep a small set of standalone agents on hosts behind a restricted zone, then reconcile both against one security baseline.
- Two procedures: Document separate upgrade and policy steps for each model so on-call staff do not guess.
- Common baseline: Define the integrations and detection coverage that every host must have, whichever model it uses.
- Inventory: Keep one list of which hosts use which model, with its owner and approval path.
- Reporting: Confirm you can see coverage across both models in one view before relying on it.
- Exit path: Plan how a host can move between models if its network or change status changes.
Before you split the estate, confirm which hosts truly cannot reach Fleet Server and whether the exceptions are documented and reviewed on a schedule.
What running each model asks of your operations team
This table compares who performs each recurring and one-time task under Fleet-managed and standalone Elastic Agent. Read it as a staffing question: the more a task falls on your team in standalone mode, the more operating skill you need in-house. Elastic describes Fleet as making agent management and upgrades considerably easier and reserves standalone mode for advanced users.
| Operating task | Fleet-managed Elastic Agent | Standalone Elastic Agent |
|---|---|---|
| Agent upgrades | Performed centrally from Kibana through Fleet, with upgrade steps driven by the Fleet interface. Confirm the procedure for your exact version in Elastic's documentation. | Each owner upgrades agents host by host, by hand. Plan a recurring change window per host group and confirm the procedure for your version. |
| Policy and integration changes | Edited once in Fleet and pushed to enrolled agents. Recurring work is mainly reviewing policy changes before rollout. | Each host's local configuration is edited and checked separately. Recurring work grows with host count and configuration drift. |
| Configuration backups | Policies live in Kibana, so your Kibana and Elasticsearch backups carry most of the agent configuration. Confirm what Fleet stores and how to restore it. | Local configuration files on each host must be backed up and version controlled by your team. This is a recurring task that is easy to miss. |
| Agent health monitoring | Agent status is visible centrally in Fleet, so one team watches one console. Confirm which health signals your version exposes. | Health checks run per host through your own tooling. Your team builds and maintains the alerting for agent liveness and errors. |
| Rollback | Rollback is coordinated from the central console for enrolled agents. Confirm the supported rollback path before you rely on it. | Rollback means restoring the previous package and configuration on each host. Test this procedure on a sample host before an incident. |
| Team skills required | Kibana administration, Fleet policy design and basic Elastic Agent operations. Training is one-time, with ongoing review of policy changes. | Linux and Windows host administration, configuration management, scripting and Elastic Agent internals. Expect this skill set to be needed continuously, not just at setup. |
| Air-gapped and locked-down hosts | Requires a reachable Fleet Server path and a plan for package distribution inside the network. Confirm the connectivity and package requirements with Elastic for your topology. | Can suit hosts with no inbound path to a management server, but package delivery and updates must be carried out through your own internal process. |
Why Elastic reserves standalone mode for advanced users
Elastic's guidance treats standalone mode as a choice that moves work onto each host owner. With Fleet, the agent policy is defined once in Kibana and pushed to every enrolled Elastic Agent, so upgrades, integration changes and settings stay consistent. In standalone mode, each host carries its own elastic-agent.yml, and the host owner edits it, tests it and upgrades the binary by hand. Every additional host adds another copy of that configuration that can drift from the others, and another upgrade that can be missed. The risk grows with the host count, not with the feature set.
An experienced team may still accept that cost on purpose. Typical reasons are hosts that cannot reach Fleet Server, isolated networks where a central management plane is not allowed, or configurations that must be fully reviewed as files before they reach a host. These cases need an owner for each host, a tested rollback path and a clear answer to who approves a change. Illustrative example: a team running a small set of air-gapped servers might prefer standalone agents because it can version every file and deploy through its own pipeline. Confirm with Elastic's install documentation which settings and integrations each mode supports before you commit to it.
If you accept standalone mode, put three controls in place before the first rollout. Keep a version inventory that records the Elastic Agent build on every host and is checked against the currently supported Elastic release lines. Store each configuration as code in version control, so every change has a diff, a reviewer and a deploy record. Keep a change log that ties each policy change to a reason and a rollback point. This is an operating judgment, not a licensing rule: the choice between modes does not change the Elastic Security feature set, which is the same under either approach.
How to choose a model and change it later
This sequence turns the Fleet-managed versus standalone question into a documented default, tested on a small group of hosts, with a review date and a clear path for moving hosts between models later.
Inventory hosts and their network reach
The platform owner and the network team list every host that will run Elastic Agent, along with its operating system, owner, and whether it can reach Kibana and the Fleet Server endpoint. Record which hosts sit in segments with restricted outbound paths, such as air-gapped or locked-down zones, and which depend on proxies or egress filtering. The step is done when every host has a row showing its reachability to Kibana and Fleet Server, and the gaps are listed with an owner for each. Confirm the Fleet Server connectivity requirements for your Elastic version in the install documentation before the inventory is closed.
Classify hosts by change control and connectivity
The security operations lead and the change advisory owner group hosts into classes based on how often they change, how strictly changes are approved, and whether they can accept central management traffic. A host that is tightly change-controlled or cannot reach Fleet is a candidate for standalone management, while hosts that need frequent policy updates and routine upgrades usually fit Fleet. The step is done when each class has a named owner, a list of member hosts, and a written reason for its assigned model. Elastic describes standalone mode as reserved for advanced users, so each standalone assignment should name who will carry the upgrade and configuration work.
Pick a default model and record exceptions
The platform owner chooses a default model for the majority of hosts, following Elastic's recommendation of Fleet management for ease of agent management and upgrades, and documents the exceptions by class. The default should match the team's ability to operate Kibana and Fleet Server, since Fleet becomes a shared dependency. The step is done when a decision note states the default, lists each exception with its justification, and names the operators responsible for Fleet Server if it is in scope. Illustrative example: a team may default most Linux servers to Fleet while keeping a small isolated segment on standalone agents with its own change owner.
Test an upgrade on a small group
The operations engineer selects a small, representative group of hosts from each class and performs an Elastic Agent upgrade in a non-production copy of the environment before touching production. For Fleet hosts, the upgrade runs from Kibana. For standalone hosts, the engineer runs the upgrade manually on each host and records every command and configuration file touched. The step is done when the test log shows the agent version before and after, the agents reconnect or report healthy, and any manual steps are written into the runbook. Confirm the upgrade procedure for your exact Elastic version in the documentation, since routines differ between models.
Test a policy change on the same group
The detection engineer applies a representative policy change to the test group, such as enabling an additional integration or adjusting a collection setting. In Fleet, the change is pushed centrally and the team checks that each agent picks it up. In standalone mode, the same change is made by editing local configuration on each host and checking the result against the other hosts in the group. The step is done when the team confirms the change is live on every test host, the event flow in Kibana matches expectations, and the team has counted the manual steps each model required. Those counts become the basis for the ongoing effort estimate in the decision record.
Record the decision and set a review date
The platform owner and the CISO's delegate write a decision record that names the default model, the exception classes, the owners for each class, the test results, and the conditions that would trigger a review, such as a new Elastic release line, a change to network segmentation, or a change in staffing. The record also sets a review date chosen by the owners, so the decision is revisited deliberately rather than left in place by default. The step is done when the record is stored with the change management system, linked from the runbook, and approved by the named owners. Ask Elastic or your partner to confirm which release lines your environment will run during the review window.
Plan moving hosts between models later
When a host needs to move from standalone to Fleet management, or the reverse, the operations team schedules the change as a planned migration rather than an ad hoc edit. The team confirms the supported migration path for its Elastic version before scheduling, since switching changes who owns the agent configuration, which upgrade routine applies, and which Kibana or Fleet Server dependencies the host gains or loses. The step is done when a migration runbook exists for each direction, a pilot host has been moved and verified, and the decision record is updated with the new host list and owner. Confirm the supported path with Elastic documentation for your version, and with your partner if the work is in scope for a fixed-scope engagement.
Questions buyers ask before choosing a model or hiring help
Is standalone Elastic Agent supported for our Elastic Security deployment?
Standalone mode is available, but Elastic positions it for advanced users and recommends Fleet management for most deployments. Standalone agents are configured by hand on each host, so every policy change, integration update and upgrade becomes a per-host task that your team owns. That can work for a small, stable estate where staff already manage configuration files and track changes outside Kibana. It gets harder with many hosts, mixed operating systems or frequent detection and policy changes. Before committing, check the Elastic agent installation documentation for the features your agent version supports in standalone mode, because support for an integration can differ by management mode.
How much operating effort does Fleet management remove from agent upkeep?
Fleet removes the per-host work of defining, changing and upgrading agents. Policies are created once in Kibana, assigned to groups of agents and pushed to every enrolled host, so a change does not require logging in to each server. Elastic's documentation says Fleet makes agent management and upgrades considerably easier. The size of the saving depends on host count, the number of distinct policies, how often agents are upgraded and whether your change process already uses configuration management. Ask any provider for an effort estimate tied to your host count that also covers Fleet Server operation, certificate handling, enrollment and rollback testing.
Can an air-gapped network use Fleet-managed Elastic Agents?
Fleet can work in an air-gapped estate only if Fleet Server, Kibana and the agents can reach each other inside the enclave, and the packages and policy content they need are available there. Confirm in Elastic's documentation, for your exact version, that the Fleet Server deployment and package distribution work without internet access. Standalone agents remove the Fleet Server dependency but move configuration and upgrade work onto your team, including transferring agent binaries and integration files through approved media. Locked-down hosts that cannot open outbound connections to a central server may suit standalone mode, but that choice should rest on a tested design and a written test plan.
What drives the cost of running Fleet or standalone agents?
Cost has three parts: licensing, infrastructure and labor. Elastic's subscriptions page places endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise, and lists the detection engine and case management under Platinum, which is no longer sold to new customers. Confirm in the subscriptions page whether Fleet management is included in the tier you plan to buy. Labor is the largest recurring item in standalone mode because each change is manual per host. Infrastructure includes Fleet Server capacity and the Elasticsearch cluster. A quote should separate one-time design and build from recurring upgrades and support, and name the subscription tier it assumes.
How long does an Elastic Agent rollout take, and what does it depend on?
No duration is supplied for this comparison, so request a timeline in writing from any provider. Rollout time depends on host count, operating system mix, network segmentation between Kibana, Fleet Server and the hosts, the number of policies and integrations you need, and whether you run a pilot group first. Air-gapped and locked-down hosts usually add test cycles for certificates, package transfer and rollback. A sound written plan includes a pilot wave, production waves with change windows and an exit criterion for each wave. Ask the provider to state its assumptions, including how long your change approvals take, since approvals often set the pace more than the technical work does.
Can our own team run Fleet-managed agents without outside help?
Possibly, if the team already administers Elasticsearch and Kibana and runs a change process for agent packages. Fleet-managed operation requires skills in Kibana role-based access, agent policy design, certificate management for Fleet Server, enrollment and upgrade sequencing. Standalone operation requires strong configuration management and file-level change control on every host, which is a different skill set. Build a skills inventory against Elastic's documentation and name who responds when an agent stops reporting. DeployOpen plans, implements, documents and supports self-hosted platforms inside your own infrastructure, and ongoing support, upgrades and continuous testing are available as retainers, so operations can move to your team in stages.
What should a written scope for agent rollout include?
A written scope should state which hosts and operating systems are covered, which integrations and policies are in scope, and whether Fleet Server is deployed and where. It should name the Elastic Stack version and subscription tier, the network and air-gap constraints, the upgrade and rollback method, the test and acceptance criteria, and handover deliverables such as runbooks. List exclusions explicitly, such as detection content authoring or log source onboarding beyond agents. DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and quotes follow from that written scope. Ask for named responsibilities on both sides, including change approvals and access to a test environment.
How DeployOpen plans, deploys and supports Elastic Agent management
DeployOpen starts by mapping which hosts, networks and change processes an Elastic Agent deployment must fit before choosing a management model. We plan, implement, document and hand over the Fleet or standalone setup inside your own infrastructure, with ongoing support available as a retainer.
How we scope
- Inventory of hosts, operating systems and network zones that will run Elastic Agent
- Written decision on Fleet-managed or standalone mode for each host group, with reasons
- Confirmation of Fleet Server placement, certificates and reachability from each zone
- Agreed deliverables, timelines and responsibilities before any work begins
How we build
- Fleet Server, agent policies and integrations configured in your Kibana instance
- Standalone configuration files built only for hosts that cannot reach Fleet
- Upgrade and policy change procedures tested in a non-production environment first
- Air-gapped or locked-down host packaging and update paths confirmed with your security team
How we hand over
- Runbooks covering enrollment, policy changes, upgrades and rollback steps
- Documented inventory of which agents run in each mode and why
- Evidence of configuration and access controls prepared for your compliance assessors
- Knowledge transfer sessions with the operators who will own the deployment
How we support
- Ongoing support, upgrades and testing available as a retainer after handover
- Review of each Elastic release line before agent upgrades are scheduled
- Periodic checks of standalone hosts that still need manual version and policy updates
- Clear ownership boundaries agreed in writing for your team and DeployOpen
