Skip to content

Releases: dragonforce2010/openmaple

OpenMaple v0.2.2 - Tenant cloud providers and Daytona sandbox

22 Jun 09:17
d1f4d2a

Choose a tag to compare

OpenMaple v0.2.2 keeps the local Docker trial path intact and adds the next cloud-provider wiring needed for teams that want to move from local evaluation to tenant-scoped cloud configuration.

What changed

  • Tenant-level Volcengine credentials are now stored separately from tenant metadata and returned through sanitized metadata responses.
  • Workspace creation can reuse tenant-level Volcengine credentials for VeFaaS runtime/sandbox provisioning.
  • Daytona is now accepted as an independent sandbox provider in onboarding, workspace settings, quickstart, runtime credential hydration, and default environment setup.
  • Local Docker onboarding remains the default no-cloud path: runtime provider and sandbox provider can both be local_docker.
  • Remote MySQL init is safer for shared deployments: schema scripts no longer run as one transaction, table-info lookups are cached, and tenant-admin backfill is set-based.

Try it locally

./scripts/setup-local-docker.sh
npm run smoke:local -- --base http://127.0.0.1:27951

Open the web console:

http://127.0.0.1:8080/?dev_login=1

The default local path starts the web console, API, MySQL, local Docker runtime pool, local Docker sandbox pool, and local dev login without requiring E2B, VeFaaS, or OAuth credentials. Model keys are only needed when running real model-backed loops.

Proof

OpenMaple v0.2.1 - Codespaces and local Docker trial

21 Jun 15:40
d940435

Choose a tag to compare

Why this release

OpenMaple now has a lower-friction first trial path: open GitHub Codespaces or run the local Docker setup script, then verify the local control plane with npm run smoke:local.

What changed

  • Added a GitHub Codespaces path for hosted evaluation.
  • Kept Docker Compose as the grounded local path for the web console, API, MySQL, local dev login, local Docker runtime pools, and local Docker sandbox pools.
  • Refreshed README, Chinese README, website CTAs, Open Graph/Twitter metadata, and the social card around the Codespaces + Docker Compose first-run story.
  • Continued to link the 2-minute product tour on the website and YouTube.

Try it

Open Codespaces:

https://codespaces.new/dragonforce2010/openmaple?quickstart=1

Or run locally:

./scripts/setup-local-docker.sh
npm run smoke:local -- --base http://127.0.0.1:27951

Then open:

Web console: http://127.0.0.1:8080/
Local login:  http://127.0.0.1:8080/?dev_login=1
API health:   http://127.0.0.1:27951/health

No E2B, veFaaS, or OAuth credentials are needed for the default local path. Model keys are only needed when you run real model-backed agent loops.

Post-release proof on main

After this release, PR #58 landed HD local-Docker proof assets on main: real 5120x2880 UI screenshots and a 2560x1440 walkthrough covering setup, smoke checks, workspace settings, runtime pool drawer, sandbox pool drawer, sessions, and quickstart UI.

Boundaries

OpenMaple is not an official Anthropic product. Provider readiness is explicit; check PROVIDER_READINESS.md before assuming an adapter is production-ready.

OpenMaple v0.2.0 - self-contained local Docker managed agents

21 Jun 14:59
a608d88

Choose a tag to compare

OpenMaple v0.2.0 makes the public first-run story self-contained: Docker Compose starts the console, API, MySQL, local dev login, local Docker runtime pools, and local Docker sandbox pools.

Try it locally

docker compose up --build
npm run smoke:local

Then open:

Console: http://127.0.0.1:27951/
Health:  http://127.0.0.1:27951/health
Login:   http://127.0.0.1:27951/v1/auth/bootstrap

What changed

  • Added a self-contained local Docker evaluation path for the managed-agent platform.
  • Default local environments now use local_docker for both agent runtime and sandbox pools.
  • Local Docker mode hides OAuth/SSO provider setup and does not require E2B or veFaaS credentials for the default path.
  • Runtime and sandbox provider boundaries remain explicit so teams can move from local Docker to cloud providers when evaluation needs it.
  • README, Chinese README, website CTA, social card, and launch discussion now point readers at the local Docker first-run path and the YouTube product tour.

Public proof

Verification on this release path

  • PR #48 added the self-contained local Docker runtime/sandbox path.
  • PR #49 refreshed README, website, and social assets around that path.
  • PR #50 made public surfaces point at the latest release instead of the old v0.1.0 tag.
  • GitHub Actions quality check is green on the release commit.

OpenMaple is not an Anthropic official product. It implements a similar managed-agent platform idea in an open stack. This release avoids production-adoption, customer-count, or benchmark claims unless the repo contains reproducible evidence.

OpenMaple v0.1.0

20 Jun 10:25
ca2aa8a

Choose a tag to compare

OpenMaple v0.1.0 is the first public release of the open-source managed-agent control plane.

Run it locally:

docker compose up --build

Then open:

Console: http://127.0.0.1:27951/
Health:  http://127.0.0.1:27951/health
Login:   http://127.0.0.1:27951/v1/auth/bootstrap

What is included:

  • React console for managed-agent resources
  • Express control-plane API for tenants, workspaces, agents, environments, sessions, vaults, deployments, and API keys
  • Self-contained Docker Compose path with local MySQL 8 and dev login
  • Session event log for durable agent runs
  • Runtime and sandbox provider boundaries for portable execution
  • Node SDK and Maple CLI entry points
  • Public GitHub Pages site with real console screenshots and a real product tour video
  • Public support, security, contribution, roadmap, and issue-template surfaces

Use it when you want the managed-agent operating model without binding runtime, sandbox, storage, or model access to one cloud. Model keys and sandbox provider keys are only needed when you run real agent loops or external tool execution.

Links:

OpenMaple is not an Anthropic official product. It implements a similar managed-agent platform idea in an open stack, and it avoids production-adoption or benchmark claims until the repo contains reproducible evidence.