Logit.io offers OpenSearch in more than one product shape. A log management stack includes OpenSearch for searching and visualizing logs you ship through Logstash. A dedicated Hosted OpenSearch cluster is for workloads where OpenSearch itself is the product — application search, custom indexes, and cluster-centric APIs. This post helps you choose without overselling either path.
Contents
Log management stacks: OpenSearch for logs
On a Logs stack, OpenSearch is the search and storage layer behind log observability. You ship with Filebeat, Elastic Agent, OpenTelemetry, Kubernetes DaemonSets, and other integrations; Logstash processes; OpenSearch indexes; Dashboards explores. Day-two work looks like Discover queries, saved searches, dashboards, retention, and alerting.
Docs for that OpenSearch surface — searching, index management, Dashboards, reporting — live under OpenSearch on log management. Prefer this shape when your primary job is “centralize logs and find incidents,” not “build a custom search application.”
Dedicated Hosted OpenSearch clusters
Hosted OpenSearch is a managed OpenSearch deployment you provision as its own stack. You create a cluster, then connect clients with the endpoint and credentials from the dashboard summary or Settings → Endpoints. Start with Creating an OpenSearch cluster and Connect to an OpenSearch cluster.
Choose dedicated clusters when you need OpenSearch as a general search/analytics engine: application search, product catalogs, custom mappings, or multi-purpose indexes that are not primarily the log pipeline. You still get Dashboards and REST access; the operating model is cluster-first rather than shipper-first.
Unlock complete visibility with hosted ELK, Grafana, and Prometheus-backed Observability
Shared APIs, MCP, and REST
Both Logs and OpenSearch stacks can use the shared OpenSearch REST API reference for programmatic search and index work. On supported plans you can also enable Hosted OpenSearch MCP for read-only investigation from tools like Cursor or Claude — useful after data is already in indexes, not a substitute for choosing the right stack type.
MCP and API keys belong in Settings → Access / Endpoints. Use REST or Developer API when you need writes or control-plane automation; hosted MCP is intentionally read-only.
A simple decision guide
- Pick a log stack if success means shipping infrastructure or app logs, exploring them in Discover, and alerting on operational patterns.
- Pick dedicated Hosted OpenSearch if success means provisioning a cluster for search/analytics workloads you index and query as a search backend.
- Use both when observability and app search are separate jobs — many teams keep logs on Log Management and run a second OpenSearch stack for product search.
Pricing and plan fit differ between log management and OpenSearch products; check current pricing pages before you commit capacity. Do not assume every OpenSearch feature on a dedicated cluster is required for basic log observability — start with the smallest product that matches the job.
Common mix-ups
People sometimes assume every OpenSearch URL on Logit is a dedicated cluster, or that log stacks cannot use the REST API. In practice, log stacks expose OpenSearch for log search and share the REST/MCP documentation with dedicated clusters where applicable — but ingestion, Logstash pipelines, and log-centric alerting are the log-management story. Dedicated clusters emphasize create/connect, cluster settings, and search application patterns.
Another mix-up is treating Hosted MCP as a reason to pick one product over the other. MCP is an investigation interface on supported plans once data exists; it does not replace choosing log observability versus app-search capacity. Start from the job (“debug production” vs “power product search”), then enable APIs or MCP as needed.
If you are unsure after reading both doc trees, open a trial Logs stack first — most new customers need log value immediately — and add a Hosted OpenSearch cluster only when a clear search workload appears.
When comparing cost, price the capacity you will actually use: log retention and ingestion on Log Management versus node sizing on Hosted OpenSearch. Trial both only when the workloads are genuinely different — duplicate stacks for the same log stream usually add cost without clarity.
Get started
New to Logit.io? Create a Logs stack from the dashboard and send a first source. Already sure you need a dedicated cluster? Follow create → connect in the Hosted OpenSearch docs, then exercise the REST API with a small index before migrating production data.