Appearance

Platform overview ​

A smplkit account is a workspace that contains your environments, your services, and the products (Config, Flags, Logging) those services depend on. Every API call, SDK initialization, and console action happens inside this account scope.

A concrete example ​

Imagine you run a SaaS product called "Acme". You sign up at app.smplkit.com — that creates an acme account with development, staging, and production environments. You have two backend services (payments and notifications) and a single-page web app (web). Each service uses the smplkit SDK with its own API key.

When payments boots in production, the SDK announces itself: service=payments, environment=production. Your developer console immediately shows the service running in production. As payments declares feature flags, registers loggers, and reads configs, those resources appear in the console — automatically, without any pre-registration step.

The building blocks ​

  • Account — The top-level container. Owned by exactly one user (the OWNER), shared with team members at varying permission levels. Holds billing, users, environments, services, and all product data.
  • Users — People with access to the account. Each user holds a role (OWNER, ADMIN, MEMBER, or VIEWER) that determines what they can do. See Roles and permissions.
  • Environments — The deployment stages your code runs in (development, staging, production, plus any per-developer or temporary environments). See Environments.
  • Services — The discrete software components inside your account (payments, web, worker). The SDK registers a service when it boots; you don't pre-create them. See Services.
  • Contexts — Typed entities your code passes to flag evaluations and other operations: a user, an account, a device. See Contexts and context types.
  • Products — The four managed capabilities smplkit provides:
    • Smpl Flags — feature flags with rules-based targeting per environment
    • Smpl Logging — runtime log-level control without redeploying
    • Smpl Config — application configuration with inheritance and environment overrides
    • Smpl Audit — append-only change-history log for both platform actions and your own application events

Each product is subscribed to independently. You can be on the Free tier of Flags and the Pro tier of Logging at the same time. See Subscriptions and entitlements.

How the SDK fits in ​

The SDK is a single client object — one per service — that talks to all three product services over HTTPS and one WebSocket. When your app starts:

  1. The SDK reads its API key, environment, and service name (from constructor, environment variables, or ~/.smplkit).
  2. It announces itself to the platform via a single bulk-context registration.
  3. It opens a WebSocket for live updates (flags changes, logger-level changes, config changes).
  4. As your code declares flags, registers loggers, or reads configs, those resources stream up to the platform.

Your code calls client.flags.boolean_flag(...), client.logging.install(), client.config.subscribe(...) — all routed through the same client. See Getting started for installation.

What the console does ​

The developer console at app.smplkit.com is where humans interact with the platform:

  • Browse and configure flags, loggers, and configs across environments
  • Manage users, invitations, and API keys
  • Promote auto-discovered resources to managed (so they're entitlement-counted and configurable)
  • Subscribe and manage billing
  • Inspect what every running service is reporting

The console and the SDK use the same API and operate on the same data. Anything you can do in the console, you can do via the API; anything the SDK reports shows up in the console immediately.

How auto-discovery changes the workflow ​

Most platforms require you to pre-register every flag, logger, and service. smplkit inverts that: the SDK reports what your code is actually doing, and the platform shows you what's running. You only configure the things you want to control.

A flag your code declared but no one has touched in the console stays "discovered" — visible, but not yet a managed resource. Once an admin configures it (sets per-environment defaults, adds rules), it becomes "managed" and counts against your subscription quota. The same model applies to loggers. See Discovered vs managed.

Where to go next ​