confish is the missing UI for the things you run - bots, scripts, cron jobs, workers. One REST API covers four surfaces: typed configuration your code fetches on demand, one-off actions it picks up on the next poll, logs you push up, and live feeds of whatever you produce.

Instead of editing .env files over SSH, tailing logs by hand, or building a small admin panel per project, you get one place for all of it: typed config, searchable logs, live feeds of whatever your code produces, and one-off actions your workers pick up - each with its own REST endpoints, plus webhooks when things change.

Official SDKs are available for the most common backend languages. Each one wraps the REST API with typed methods, typed errors, automatic retries, an action consumer with adaptive backoff, and a webhook signature verifier. If your language isn't listed, the REST API is documented below and works from anywhere.

npm install @confish/sdk

pip install confish

go get github.com/confishhq/confish-go

composer require confish/sdk

cargo add confish

Each SDK exposes the same surface: fetch and write configuration, send logs, run an action consumer with graceful shutdown, and verify webhook signatures. The sections below describe the underlying REST API the SDKs call - useful if you're using a language without an SDK or want to understand what's happening under the hood.

All API requests are authenticated using Bearer tokens. Each environment has its own API key, prefixed with confish_sk_.

Include the API key in the Authorization header of every request:

Authorization: Bearer confish_sk_your_api_key_here

Field definitions enforce a typed schema across all environments. When you fetch configuration via the API, values are automatically cast and validated based on these types.

"site_name": "My Application"

"max_upload_mb": 25

"maintenance_mode": false

"launch_date": "2026-03-16"

"allowed_origins": ["https://example.com", "https://app.example.com"]

confish can notify your application when configuration values change by sending HTTP POST requests to a URL you configure per environment.

{
  "event": "environment.updated",
  "timestamp": "2026-04-05T12:00:00+00:00",
  "application": {
    "name": "My App"
  },
  "environment": {
    "name": "Production",
    "env_id": "a1b2c3d4e5f6",
    "url": "https://confi.sh/c/a1b2c3d4e5f6"
  },
  "changes": ["max_upload_mb"],
  "values": {
    "site_name": "My Application",
    "max_upload_mb": 25,
    "maintenance_mode": false
  }
}

{
  "event": "environment.updated",
  "timestamp": "2026-04-05T12:00:00+00:00",
  "application": {
    "name": "My App"
  },
  "environment": {
    "name": "Production",
    "env_id": "a1b2c3d4e5f6",
    "url": "https://confi.sh/c/a1b2c3d4e5f6"
  },
  "changes": ["max_upload_mb"]
}

X-Confish-Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000

X-Confish-Signature: ts={unix_timestamp};sig={hmac_sha256_hash}

import { verifyWebhook } from '@confish/sdk/webhook';

app.post('/webhook', express.text({ type: '*/*' }), async (req, res) => {
  let payload;
  try {
    payload = await verifyWebhook({
      body: req.body,
      signature: req.headers['x-confish-signature'] as string,
      secret: process.env.CONFISH_WEBHOOK_SECRET!,
    });
  } catch (err) {
    // Invalid signature or timestamp outside tolerance
    return res.status(401).send(err.message);
  }

  // Handle the webhook event...
  res.sendStatus(200);
});

confish includes a simple logging API that lets you send log entries from your application and view them per environment in the dashboard. This is useful for tracking deployments, errors, or any event related to your configuration.

Sending a Log

curl -X POST https://confi.sh/c/a1b2c3d4e5f6/log \
  -H "Authorization: Bearer confish_sk_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"level": "info", "message": "User logged in"}'

See Store Log Entry for the full reference and SDK examples.

Log Levels

Retention

Logs are automatically pruned based on your plan. The Free plan retains up to 500 logs per environment for 14 days. The Pro plan retains up to 5,000 logs per environment for 30 days. When the limit is reached, the oldest logs are removed first.

Native logging adapters

Calling the SDK's log methods directly is the zero-dependency path. From 0.3.0, each SDK also implements its language's native logging interface, so the log calls you already make flow to confish with a config change - keep your existing logger, add confish as a sink. Adapters buffer entries in memory and flush in batches (at 50 entries or every 5 seconds), stamp each entry with the time it was logged rather than the time it was sent, and never raise into your code path - if delivery fails, entries are counted as dropped and your app keeps running.

handler, _ := confish.NewSlogHandler(client, confish.SlogHandlerOptions{})
defer handler.Close()
slog.SetDefault(slog.New(handler))

slog.Info("crawl finished", "pages", 12480)

JavaScript has no adapter by design - the ecosystem has no consensus logging interface - so client.logs (including batch writes via writeBatch) is the JS story.

Actions let you send one-time commands from the dashboard to your applications. The consumer polls for pending actions, acknowledges them, reports progress, and marks them as completed or failed.

List Pending Actions

Returns pending, non-expired actions ordered oldest first.

Acknowledge Action

Call this immediately when picking up an action to signal that processing has started.

Report Progress

Append a timeline update. Each update has a message and optional data object.

Complete or Fail

Both accept an optional result object for final output or error details.

Full Example

The raw curl flow drives the full lifecycle manually. Each SDK ships a consume() helper that polls, acknowledges, runs your handler, and reports the outcome - including idempotent skip on 409 and adaptive backoff when idle.

# 1. Poll for actions
curl https://confi.sh/c/a1b2c3d4e5f6/actions \
  -H "Authorization: Bearer confish_sk_your_api_key"

# 2. Acknowledge
curl -X POST https://confi.sh/c/a1b2c3d4e5f6/actions/ACTION_ID/ack \
  -H "Authorization: Bearer confish_sk_your_api_key"

# 3. Report progress
curl -X POST https://confi.sh/c/a1b2c3d4e5f6/actions/ACTION_ID/update \
  -H "Authorization: Bearer confish_sk_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"message": "Flushing cache", "data": {"keys": 512}}'

# 4. Complete
curl -X POST https://confi.sh/c/a1b2c3d4e5f6/actions/ACTION_ID/complete \
  -H "Authorization: Bearer confish_sk_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"result": {"flushed": 512, "duration_ms": 84}}'

Expiry

Actions expire after a configurable TTL (set when dispatching from the dashboard, default 1 hour, max 24 hours). Expired actions cannot be acknowledged, updated, or completed. Consumers should check for and skip expired actions.

Templates

If you find yourself dispatching the same action repeatedly, you can save it as a template from the dispatch sheet - tick Save as template, give it a name, and submit. Templates are application-wide, so the same template is available when dispatching from any of that application's environments.

Pick a template from the Load from template dropdown at the top of the sheet to hydrate the form with its type, parameters, and expiry - all fields stay editable, so templates act as defaults you can tweak before sending. Delete a template from the same dropdown using the trash icon next to its name; this doesn't affect any previously dispatched actions, since each action stores its own copy of the values it was sent with.

Feeds are typed collections of living state you push into confish - scrape results, job runs, incidents, sensor readings. Define the fields once, pick a layout (cards, table, compact list, or hero), and the dashboard renders whatever you send. Items can be updated in place, deleted, or given a TTL so they clean themselves up. Hero renders each item big and centered - push one for singleton state like a quote of the day or today's draw, or a few and they stack as equally-weighted blocks in the sort order.

Feeds are created and configured in the dashboard (the Feeds tab on any environment). The API below is how you manage items. Feed writes only require a valid API key - the config write access toggle does not apply.

Upsert Item

Create or update an item. You supply the ID - use something natural to your domain (a fixture ID, an order ID, a listing URL hash). The same ID always updates the same item, so crash-and-retry loops are safe by default.

curl -X PUT "https://confi.sh/c/a1b2c3d4e5f6/feeds/jobs/items/item-1" \
  -H "Authorization: Bearer confish_sk_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"data": {"job":"example","pages":123,"status":"example"}, "ttl": 86400}'

Returns 201 when the item was created, 200 when updated. If the environment's partition is at its plan cap, creates are rejected with a 422 - feeds hold living state, so nothing is silently pruned. Updates to existing items always succeed.

The feed helper is available in every official SDK.

Replace All Items

Declaratively replace the environment's entire partition in one request: send {"items": [{"external_id", "data", "ttl"?}, ...]} and the feed becomes exactly those items - existing IDs update in place, new IDs are created, and anything absent is deleted. An empty list clears the feed. Built for sync-style jobs (a daily cron pushing its full dataset) - one request and one live update for viewers instead of hundreds. All-or-nothing: any invalid item rejects the whole request with a 422 and nothing written, and payloads over the plan's item cap are rejected the same way. Returns {"created", "updated", "deleted"} counts. In the SDKs this is feed.replace(items).

List Items

Returns the environment's live items, newest first. Expired items are never included.

Delete Item

Removes an item from the environment. Idempotent - deleting an item that is already gone returns 204, so retries never error. For items with a natural end (a finished run, a resolved incident), prefer setting a ttl on the final upsert over an explicit delete: the item lingers visibly for a while, then cleans itself up even if your script crashes first.

Sharing feeds publicly

Any feed can be published at a read-only public link - a zero-build live dashboard for whatever you publish. Sharing is per feed, per environment: you can make production's items public while staging stays private. Enable it from the feed's Share dialog on the environment's Feeds tab, where you can also give the page its own title. The link is unguessable and marked noindex; viewers see the feed's items and nothing else - no app, environment, or config details. Disable or regenerate the link at any time. Viewers can install a shared page as an app on their phone or desktop - each share carries its own web app manifest, named after the share. Public share links are a Pro feature; your code needs no changes.

Boards

A share publishes one feed; a board composes several - feeds from any of your applications, each section pinned to the environment of your choice, stacked in the order you set. Manage them from Boards in the sidebar: pick a title, add sections (each heading defaults to the feed name and can be renamed), and flip the public link on when you're ready - boards start as private drafts. Each section renders with its feed's own layout, so a hero section can headline the board above a table and a list. A board's public page carries the same guarantees as shares: unguessable /b/ link, noindex, live updates, installable as its own app, and nothing about your apps or environments is ever shown. Boards are a Pro feature.

confish offers a generous free tier for side projects and a Pro plan for higher limits.