Launch a Search Workspace

The search-workspace stack stands up a complete search and analytics environment in one launch. You get a managed OpenSearch cluster and an OpenSearch Dashboards application already attached to it, so you can index documents, run queries, and build visualizations from a single browser tab without wiring anything by hand.

What the search workspace is, and who it is for

OpenSearch is a distributed search and analytics engine: you write JSON documents into indices, and it builds inverted indexes so you can run full-text search, filters, and aggregations over them in milliseconds. OpenSearch Dashboards is the companion web app: it gives you Discover for ad-hoc search, a visualization and dashboard builder, and Dev Tools, an in-browser console for sending raw queries to the cluster.

This stack is for teams who want both pieces, already connected:

Engineers building search into a product who need a cluster plus a console to develop and test queries against.
Data and operations teams who want to explore log, event, or metric data with Discover and pin the result as a dashboard.
Anyone who wants OpenSearch and its UI to stay in their own EU-resident infrastructure rather than a third-party SaaS.

Composition

The stack composes two FoundryDB primitives, wired together at launch:

Resource	What it is	Spec
`search`	A managed OpenSearch 2.19 cluster. It is the search and analytics engine and the durable store for your indices.	tier-2, 50 GB maxiops storage
`dashboards`	A hosted OpenSearch Dashboards application, attached to the cluster. It serves Discover, the dashboard builder, and Dev Tools.	tier-2, 10 GB standard storage

The OpenSearch cluster is both the data plane and the backing store. Dashboards is the presentation and exploration layer on top. There is a detail worth knowing up front: Dashboards has no database of its own. It persists its own saved objects, index patterns, saved searches, visualizations, and dashboards, into a system index on the OpenSearch cluster. The cluster is therefore both the data you explore and the place your saved views live.

search-workspace stack composition & launch

RUNNING Stack wired · search workspace live

Stack Templatesearch-workspacelaunch ⇉OpenSearchcluster · :9200OpenSearch Dashboardsattach + saved objects → clusterserve →Search WorkspaceDiscover · dashboards · Dev Tools

Template · launchOpenSearch (cluster)OpenSearch Dashboards (console)wiring (attach + saved objects)

Prerequisites

An API token. See Authentication.

Unlike the rag-chatbot stack, the search workspace does not include an inference resource, so you do not need a configured inference provider to launch it.

Export your token for the commands below:

export FOUNDRYDB_TOKEN="your-api-token"

Launch it

Option A: one-click in the console

Open the Stacks catalog in the console, pick Launch a search workspace, review the cost preview, and click Launch. The console runs the same preview, accept, and launch flow described below and shows the live Dashboards endpoint once the stack reaches Running.

Option B: the API

The launch is a two-step flow: preview the cost first, then send the launch request with the cost you accepted. This guarantees you always see an up-to-date estimate before any billable resource is created.

1. Preview the cost

curl -X POST https://api.foundrydb.com/stacks/preview \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template_name": "search-workspace"}'

The response breaks the cost down per resource:

{
  "template_name": "search-workspace",
  "currency": "EUR",
  "monthly_total": 96.00,
  "line_items": [
    {
      "symbolic_name": "search",
      "kind": "database",
      "description": "OpenSearch tier-2 (2 vCPU, 4 GB) + 50 GB maxiops storage",
      "monthly_cost": 62.00,
      "is_ceiling": false
    },
    {
      "symbolic_name": "dashboards",
      "kind": "app",
      "description": "OpenSearch Dashboards app tier-2 + 10 GB standard storage",
      "monthly_cost": 34.00,
      "is_ceiling": false
    }
  ],
  "warnings": []
}

monthly_total is the figure you pass to the launch request. The cost preview is computed fresh on every call, so always preview right before launching. The figures above are illustrative; use the value the API returns.

2. Accept and launch

Pass the monthly_total from the preview as accepted_monthly_cost:

curl -X POST https://api.foundrydb.com/stacks \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-search",
    "template_name": "search-workspace",
    "accepted_monthly_cost": 96.00
  }'

The response is 201 Created with the stack in Pending status. Capture its id:

export STACK_ID="the-id-from-the-response"

If accepted_monthly_cost has drifted from the current estimate by more than EUR 0.01, the launch returns 409 Conflict and you re-preview. If it is omitted entirely, the launch returns 400 Bad Request.

3. Poll for status

The stack provisions asynchronously. Poll GET /stacks/{id} until status reaches Running:

curl https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

Typical progression is Pending then Provisioning then Wiring then Running. The OpenSearch cluster provisions first, then Dashboards; Dashboards optimizes its bundles on first boot, so allow it a couple of extra minutes to report healthy. Once the stack is Running, the endpoint_url field carries the live Dashboards URL:

{
  "id": "...",
  "name": "my-search",
  "status": "Running",
  "endpoint_url": "https://my-search-dashboards.foundrydb.com",
  "resources": [
    { "symbolic_name": "search", "kind": "database", "status": "Running", "service_id": "..." },
    { "symbolic_name": "dashboards", "kind": "app", "status": "Running", "service_id": "..." }
  ]
}

First run

Open the endpoint_url in a browser. OpenSearch Dashboards is gated by the cluster's own security plugin, so you sign in with a database user from the OpenSearch cluster, not a separate app login. Reveal a user and password from the search resource:

# Find the cluster service id
curl https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
  | jq -r '.resources[] | select(.symbolic_name=="search") | .service_id'

# List users on the cluster, then reveal one user's password
curl https://api.foundrydb.com/managed-services/<search-service-id>/database-users \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

curl -X POST \
  https://api.foundrydb.com/managed-services/<search-service-id>/database-users/<username>/reveal-password \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

Index some data with Dev Tools

Dashboards ships an in-browser console. Open Dev Tools from the left navigation and run a few requests against the cluster directly. First, index a couple of documents into an articles index:

POST articles/_doc
{ "title": "Getting started with OpenSearch", "tags": ["search", "guide"], "views": 120 }

POST articles/_doc
{ "title": "Building dashboards", "tags": ["analytics"], "views": 64 }

Then run a full-text search:

GET articles/_search
{ "query": { "match": { "title": "dashboards" } } }

Dev Tools shows the JSON response inline, with the matching document and its relevance score. This is the same REST API your application code calls; the console just gives you a fast way to develop and test queries.

Build a Discover view

Discover is the point-and-click search interface. To use it, Dashboards needs an index pattern that tells it which indices to read.

Go to Stack Management, then Index Patterns, and create a pattern matching articles.
Open Discover and select the pattern. You see your indexed documents as a searchable, filterable list.
Add a search bar query such as tags: analytics to filter, and pin the columns you care about.

Turn it into a dashboard

From a Discover view or the Visualize app, build a visualization, for example a metric showing total views or a bar chart of documents per tag, then add it to a new dashboard under the Dashboard app. Save it.

Here is the detail that matters: when you save that index pattern, search, visualization, or dashboard, Dashboards writes it into a system index on the OpenSearch cluster, not to local disk on the app. Your saved work lives in the cluster you own. It is backed up with the cluster and survives a restart or replacement of the Dashboards app.

How the wiring works

The stack engine does not introduce a new provisioning path. It calls the same APIs you would call yourself, in dependency order, and injects the configuration each resource needs.

For the search workspace:

The search resource is provisioned first: a managed OpenSearch 2.19 cluster with its security plugin and TLS in place.
The dashboards resource is provisioned and attached to the cluster. During the Wiring phase, the engine injects the cluster endpoint and a credential into the Dashboards app so it can reach OpenSearch. Dashboards uses the cluster as both its data source (the indices you query) and its metadata store (the system index where its saved objects live).
Dashboards connects on first boot, optimizes its UI bundles, and comes up serving Discover, the visualization builder, and Dev Tools.

There is no cluster endpoint to copy, no firewall rule to open by hand, and no environment variable to paste into a settings panel. The Dashboards app already knows where the cluster is, how to authenticate to it, and where to keep its saved objects the moment the stack reaches Running. Traffic between Dashboards and the cluster travels over the platform's private network.

Cost and EU residency

The search workspace costs the sum of its two resources, shown in your cost preview at launch (a tier-2 OpenSearch cluster plus a tier-2 Dashboards app). Each child resource is an ordinary service in your account, billed through your normal plan. You can scale either one individually after launch: bump the cluster to a larger tier or grow its storage as your indices grow, and resize the Dashboards app independently.

Both resources are EU-resident. The OpenSearch cluster, the Dashboards app, and the traffic between them all stay within the platform's European footprint. Residency is not a setting you remember to flip; it is where the platform runs.

Teardown

Delete the whole stack with one call:

curl -X DELETE https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

Returns 202 Accepted. The reconciler deletes the Dashboards app first, then the OpenSearch cluster, in reverse dependency order. Because Dashboards stores its saved objects on the cluster, deleting the stack removes both your indexed data and your saved views together. Teardown is atomic and leaves no orphaned cluster or app behind. It is irreversible, so snapshot or export anything you want to keep first.

Next steps

Stacks Overview: how stacks compose primitives, the catalog, and the lifecycle.
Launch a Stack: the full preview, launch, retry, and teardown reference.
OpenSearch: scale, snapshot, secure, and connect directly to the cluster under your workspace.
Upgrades: adopt new template versions of the stack in place.

What the search workspace is, and who it is for​

Composition​

Prerequisites​

Launch it​

Option A: one-click in the console​

Option B: the API​

1. Preview the cost​

2. Accept and launch​

3. Poll for status​

First run​

Open Dashboards and sign in​

Index some data with Dev Tools​

Build a Discover view​

Turn it into a dashboard​

How the wiring works​

Cost and EU residency​

Teardown​

Next steps​