dockit vs opensearch dashboards

OpenSearch Dashboards is the standard web interface for OpenSearch. It's built for visualizations and monitoring, but it's often too heavy for daily query development. Running it requires a dedicated service, and the 10-30 second startup time and 500MB+ RAM overhead can get in the way when you just need to run a quick query.

DocKit is a native desktop app designed specifically for querying OpenSearch. It starts in under 2 seconds, connects directly to your cluster, and keeps your queries stored locally without any server-side dependencies.

Download DocKitView on GitHub

head-to-head comparison

	DocKit	OpenSearch Dashboards
Type	Native desktop app	Web app (requires server)
Startup time	< 2 s	10–30 s
RAM usage	~150 MB	500 MB+
Requires Dashboards server	❌	✅
Offline mode	✅	❌
Query editor	Monaco + JSON5 + autocomplete	Basic Dev Tools console
AI query assistant	✅ (OpenAI, Anthropic, DeepSeek, and more)	❌
Query persistence	✅ Local files (Git-friendly)	✅ Saved queries (server-side)
Index & cluster management	✅	✅
Visualizations / dashboards	❌	✅
Observability / tracing	❌	✅
Alerting	❌	✅
DynamoDB / Elasticsearch	✅	❌
AWS OpenSearch Service	✅	✅ (hosted)
Open source	✅ Apache 2.0	✅ Apache 2.0
OS version support	1.x – 3.x+	Version-locked to cluster

when dockit is the better choice

working with aws opensearch service

AWS OpenSearch Service gives you a managed Dashboards endpoint that can be frustrating to configure and is always version-locked to your cluster. DocKit skips the Dashboards setup by connecting directly to the OpenSearch REST API using your AWS credentials (access keys, IAM roles, or profiles).

faster query loops

Browser-based tools have inherent friction. The Dashboards Dev Tools tab has to load inside a Dashboards instance within your browser. DocKit is a native app that's ready to use in about 2 seconds. If you're running dozens of queries every day, that's a lot of waiting you don't have to do.

ai-assisted query generation

DocKit lets you describe a query in plain English and generates the OpenSearch DSL for you. It uses your actual index mapping as context so the results are relevant. It works with OpenAI, Anthropic, DeepSeek, and more AI providers using your own API key. OpenSearch Dashboards has no equivalent for this.

queries in version control

DocKit stores your history and saved queries as local files. This makes it easy to commit them to Git or share them with teammates as code. Your query records stay with you, independent of whatever Dashboards instance you're currently using.

using elasticsearch or dynamodb

You can manage OpenSearch, Elasticsearch, and DynamoDB in the same app. You don't have to juggle multiple tools when switching between different cluster types.

when opensearch dashboards is the better choice

Stick with OpenSearch Dashboards when you need:

• Dashboards and visualizations: the built-in engines (Lens, TSVB) are better for charts intended for stakeholders.
• Alerting and monitors: rule-based alerting that's integrated directly into the cluster.
• Observability pipelines: features like Trace Analytics, Jaeger/Zipkin integrations, and specific log analytics views.
• Security plugin UI: managing FGAC, roles, and audit logs via the Security plugin.
• Shared access: when you need a browser URL that anyone on the team can access without installing software.

Most teams find a balance by using both: DocKit for the engineers writing queries, and Dashboards for shared monitoring and stakeholder reporting.

migration workflow

If you're moving from OpenSearch Dashboards to a desktop client, the transition is straightforward — you don't have to drop Dashboards entirely.

1. Collect your saved queries

Open Dev Tools in Dashboards and gather the requests your team reruns during development, incident reviews, or release validation. Copy saved queries from the Dev Tools console into versioned files so they stop living only inside browser history.

2. Set up connection profiles

Install DocKit and create connection profiles for each environment — local, staging, production. Use named profiles so switching environments is explicit and repeatable:

• Self-hosted: host, port, and credentials (Basic Auth, API Key, or none)
• AWS OpenSearch Service: domain endpoint + AWS credentials (access keys or IAM profile)

3. Recreate queries in JSON5

Convert strict JSON from Dashboards into JSON5 — it supports inline comments and trailing commas, making queries easier to maintain:

GET /orders/_search
{
  "query": {
    "bool": {
      "filter": [
        { "range": { "createdAt": { "gte": "now-7d/d" } } },
        { "term": { "status": "paid" } }
      ]
    }
  },
  "size": 100
}

GET /orders/_search
{
  // Paid orders from the last 7 days
  query: {
    bool: {
      filter: [
        { range: { createdAt: { gte: 'now-7d/d' } } },
        { term: { status: 'paid' } }
      ]
    }
  },
  size: 100
}

4. Run both tools side-by-side

Keep Dashboards available for visualizations, alerting, and shared views. Use DocKit for daily query authoring and environment switching. Run both for one to two weeks — that overlap is enough to confirm whether the lighter workflow fits your team.

the query editor difference

The Dev Tools console in OpenSearch Dashboards is functional but limited. It's essentially the same tool inherited from Kibana:

• Strict JSON is required, which means no inline comments or trailing commas.
• Autocomplete for fields can be slow to update after mapping changes.
• There's no AI support.
• Saved queries are stored on the server and tied to a specific instance.
• You can't easily export queries as curl commands.

DocKit uses a Monaco-based editor that's much more flexible:

• JSON5 support: add comments to your queries and use trailing commas without breaking things.
• Live autocomplete: field suggestions are pulled from your mapping as soon as you connect.
• DSL validation: the editor checks your syntax against the OpenSearch Query DSL.
• One-click exports: auto-formats on save and lets you copy any query as a curl command.
• Multi-tabbing: keep several queries open and run them simultaneously.
• Local history: your entire execution history is saved locally and is fully searchable.

connecting dockit to opensearch

self-hosted opensearch

1. Download DocKit for your OS.
2. Go to New Connection and select OpenSearch.
3. Enter your host, port, and credentials (Basic Auth, API Key, or none).
4. Click Connect.

aws opensearch service

1. Go to New Connection and select OpenSearch.
2. Enter your domain endpoint (the https://... URL).
3. Select AWS credentials authentication. DocKit will use your ~/.aws/credentials or environment variables.
4. Click Connect.

For VPC clusters or fine-grained access control, check the connection guide.

opensearch version support

DocKit works with OpenSearch 1.x, 2.x, and 3.x because it uses the standard REST API. Unlike OpenSearch Dashboards, it isn't version-locked to the cluster it's talking to.

frequently asked questions

Is DocKit a full OpenSearch Dashboards replacement? For query development and index management, yes. For dashboards, observability, and alerting, no. Most teams use both.

Does it work with Amazon OpenSearch Service? Yes. DocKit connects to the AWS OpenSearch Service REST endpoint using your AWS credentials. Use Basic Auth for HTTP-level credentials or AWS SigV4 signing (roadmap — check GitHub for status).

Can I use DocKit with OpenSearch behind a VPN? Yes. As long as DocKit can reach the OpenSearch REST port (default 9200), it works. You can point DocKit at localhost if you have a VPN or SSH tunnel running.

Does it support OpenSearch Serverless? OpenSearch Serverless requires SigV4 signing for every request. Standard credential auth isn't enough. Check the GitHub issues for the current status.

---

→ DocKit full feature overview · OpenSearch GUI client page · OpenSearch GUI deep-dive