Skip to content

feat(dev): run agentex locally without Docker #353

Open
aringuyen3 wants to merge 4 commits into
mainfrom
aringuyen/run-local-no-docker
Open

feat(dev): run agentex locally without Docker #353
aringuyen3 wants to merge 4 commits into
mainfrom
aringuyen/run-local-no-docker

Conversation

@aringuyen3

@aringuyen3 aringuyen3 commented Jul 9, 2026

Copy link
Copy Markdown

What

Adds a docker-free mode that runs the full agentex backend as host processes with embedded datastores — a lighter alternative to the Docker Compose stack, closer to a one-command langgraph dev-style workflow.

./dev.sh no-docker                    # whole stack, no Docker
./dev.sh no-docker --lean             # Postgres + Redis + API + MongoDB only (no Temporal/OTel)
./dev.sh no-docker --no-temporal      # skip Temporal + the worker
./dev.sh no-docker --mongo-uri <uri>  # use an external MongoDB instead of a local mongod

The bare ./dev.sh (Docker) is unchanged and now also accepts an explicit ./dev.sh docker alias. The docker-free mode is also available as make dev-no-docker and python -m scripts.dev_nodocker.

Why

Standing up a local environment previously required the full Docker stack. This lets a developer run the backend with a single command and no Docker daemon:

  • Postgres via bundled pgserver (unix socket) and Redis via bundled redislite
  • a Temporal dev server + Web UI and the agentex worker
  • a local mongod — always started; the stack requires it (the Temporal worker builds Mongo-backed repositories at boot)
  • an optional OpenTelemetry collector

It runs migrations, supervises uvicorn + the worker, and tears everything down cleanly on Ctrl-C / SIGTERM. --ephemeral uses a throwaway data dir; --mongo-uri points at an existing MongoDB instead of launching a local mongod.

App-side change

Safe no-op wherever the backend runs in Docker / staging / prod (the env var it keys on is unset there):

ACP host rewrite for docker-free mode. Agents register their ACP URL at host.docker.internal (the SDK default, so a Docker backend can reach an agent on the host), which a host-process backend can't resolve. The runner sets AGENTEX_ACP_HOST_OVERRIDE=127.0.0.1 and the backend rewrites only that sentinel host to the override when dialing agents — in the ACP request path, the agent-API-key proxy path, and the Temporal healthcheck. When the env var is unset, the stored URL is used verbatim. Default-scaffolded agents work without manifest edits.

Also

  • Fix a frontend dev-server process leak in dev.sh (kill the whole make → npm → next tree and sweep orphans; report status by listening port).
  • Correct the MongoDB (brew trust first) and OpenTelemetry (release binary; not in Homebrew) install commands.
  • Add a dev-no-docker uv dependency group (pgserver, redislite, greenlet) pulled only for docker-free mode.
  • Document docker-free mode in README.md and CLAUDE.md.

Contract note

The runner is a package (scripts/dev_nodocker/), so the direct invocation is python -m scripts.dev_nodocker (not python scripts/dev_nodocker.py). ./dev.sh no-docker and make dev-no-docker are unchanged for callers.

Testing

Manually exercised on macOS (Docker stopped):

  • Full stack and --lean — the API passes /healthz within ~1s and /readyz reports Postgres, Redis, and MongoDB all healthy; the Temporal worker stays up; teardown frees all ports with no orphaned processes.
  • Fail-fast path: full mode with mongod absent aborts with an actionable install message (or point at an external instance with --mongo-uri).
  • Booted end-to-end via python -m scripts.dev_nodocker; agents scaffolded by agentex init connect without manifest edits (ACP host rewrite).

Platform support: macOS and Linux only. Not supported on native Windows — the embedded Redis (redislite) ships no Windows server build; run it under WSL2, where redislite/pgserver/mongod behave as on Linux (WSL2 path not yet verified).

Greptile Summary

This PR adds a docker-free local development mode (./dev.sh no-docker) that runs the full agentex backend as host processes with embedded Postgres (pgserver), Redis (redislite), a Temporal dev server, a local mongod, and an optional OTel collector — no Docker daemon required. A companion resolve_acp_url utility rewrites host.docker.internal ACP URLs to 127.0.0.1 when AGENTEX_ACP_HOST_OVERRIDE is set (a no-op in Docker/staging/prod), applied consistently across the ACP request path, the agent-API-key proxy, and the Temporal healthcheck activity.

  • New scripts/dev_nodocker package: pure config.py, provisioning in services.py, subprocess plumbing in supervise.py, and orchestration in runner.py; returns exit code 1 on unexpected process crash and 0 on clean Ctrl-C/SIGTERM.
  • dev.sh extended: adds no-docker subcommand, kill_tree for cleaner frontend teardown, mode-file tracking so stop/status/restart work correctly regardless of which mode was last used, and a best-effort otelcol-contrib release-binary installer.
  • App-side ACP rewrite: resolve_acp_url is inserted at all three agent-dial sites; the env var is unset everywhere except the no-docker runner subprocess environment, making the change a true no-op on Docker/prod paths.

Confidence Score: 5/5

Safe to merge — the app-side changes are a genuine no-op in Docker/staging/prod and the new dev tooling is well-isolated.

The resolve_acp_url rewrite only activates when AGENTEX_ACP_HOST_OVERRIDE is set, which happens exclusively inside the no-docker runner subprocess environment. All three ACP dial sites are covered consistently. The runner returns the correct non-zero exit code on unexpected crashes and tears down embedded datastores cleanly. The remaining findings are minor style and dev-ergonomics nits that do not affect runtime correctness.

No files require special attention beyond the noted nits in .gitignore (dead path entry), Makefile (bare TODO), supervise.py (fire-and-forget task reference), and acp_url.py (INFO vs DEBUG log level).

Important Files Changed

Filename Overview
agentex/src/utils/acp_url.py New utility that rewrites host.docker.internal ACP URLs to a loopback override in no-docker mode; correctly no-ops in Docker/prod. INFO-level log fires on every ACP dial.
agentex/scripts/dev_nodocker/runner.py Orchestrates startup/teardown of embedded services; returns exit code 1 on unexpected process crash and 0 on clean signal-driven stop. Teardown order and signal handling look correct.
agentex/scripts/dev_nodocker/supervise.py Subprocess plumbing — spawn, wait-for-port, migrate, terminate. Fire-and-forget asyncio.create_task in spawn() has no saved reference, a documented asyncio caveat.
agentex/scripts/dev_nodocker/services.py Provisions Postgres, Redis, Temporal, MongoDB, and OTel as host processes; fail-fast on missing required services; graceful teardown on stop.
agentex/scripts/dev_nodocker/config.py Pure config and argument parsing for the no-docker runner; no side effects; --lean/--full/--ephemeral flags correctly handled.
agentex/src/domain/use_cases/agents_acp_use_case.py Adds resolve_acp_url to the ACP URL resolution path; truthiness fallback chain for deployment vs agent URL is preserved correctly in the refactor.
agentex/src/domain/use_cases/agent_api_keys_use_case.py Minimal change — wraps agent.acp_url in resolve_acp_url before constructing the proxy URL; correct no-op in Docker/prod.
agentex/src/temporal/activities/healthcheck_activities.py Rewrites ACP URL before the healthcheck HTTP call so the Temporal worker dials the correct address in no-docker mode.
dev.sh Adds no-docker subcommand, kill_tree for frontend cleanup, mode-file tracking, and otelcol binary install. Checksum-bypass on OTel download failure was noted in a prior review.
.gitignore Root .gitignore entry says agentex/.dev-local/ but the actual generated directory is agentex/.dev-nodocker/; the typo is harmless because agentex/.gitignore has the correct entry.
agentex/Makefile Adds dev-no-docker target; TODO comment for stopping the local dev server is missing a ticket number per team conventions.
agentex/pyproject.toml Adds dev-no-docker dependency group (pgserver, redislite, greenlet); also adds them to the test group for test scenarios without Docker.

Sequence Diagram

sequenceDiagram
    participant devsh as dev.sh no-docker
    participant runner as scripts.dev_nodocker.runner
    participant svc as services.py
    participant sup as supervise.py
    participant api as uvicorn (API)
    participant worker as Temporal worker
    participant agent as Agent process

    devsh->>runner: uv run python -m scripts.dev_nodocker
    runner->>svc: provision_postgres()
    runner->>svc: provision_redis()
    runner->>svc: provision_mongo()
    runner->>svc: provision_temporal()
    runner->>sup: run_migrations()
    runner->>sup: spawn(api, uvicorn)
    activate api
    runner->>sup: spawn(worker, run_worker.py)
    activate worker
    runner->>sup: wait_for_health(:5003/healthz)
    sup-->>runner: healthy

    Note over api,agent: ACP host rewrite active (AGENTEX_ACP_HOST_OVERRIDE=127.0.0.1)

    api->>agent: resolve_acp_url(host.docker.internal:port) to 127.0.0.1:port
    worker->>agent: healthcheck via resolve_acp_url()

    devsh->>runner: SIGTERM (Ctrl-C or dev.sh stop)
    runner->>sup: terminate(worker)
    deactivate worker
    runner->>sup: terminate(api)
    deactivate api
    runner->>svc: temporal.shutdown()
    runner->>svc: teardown_redis()
    runner->>svc: pg_server.cleanup()
Loading

Reviews (6): Last reviewed commit: "fix commnet" | Re-trigger Greptile

Context used:

  • Rule used - Include ticket numbers in TODO comments to make cl... (source)

Learned From
scaleapi/scaleapi#126926

@aringuyen3
aringuyen3 requested a review from a team as a code owner July 9, 2026 14:48
Comment thread agentex/src/domain/use_cases/agents_acp_use_case.py Outdated
Stand up the full backend as host processes with embedded datastores — no
Docker daemon required — as a lighter alternative to the container stack.

`./dev.sh local` (also `make dev-local` / `python -m scripts.dev_local`) provisions:
- Postgres via bundled pgserver (unix socket) and Redis via bundled redislite
- a Temporal dev server + UI and the agentex worker (--no-temporal to skip)
- a local mongod, required for the full stack (--no-mongo / --lean to skip)
- an optional OpenTelemetry collector (--no-otel to skip)
then runs migrations, supervises uvicorn + the worker, and tears everything down
cleanly on SIGINT/SIGTERM. --lean is a minimal Postgres+Redis+API stack; --ephemeral
uses a throwaway data dir. The runner is a small scripts/dev_local package
(config / services / supervise / runner) so the pure config/env layer stays testable.

App-side changes to make the no-Docker path robust (all no-ops when Mongo is
configured, as it always is in Docker/prod):
- The Temporal worker no longer crashes when MongoDB is unavailable — the Mongo CRUD
  adapter tolerates an unset database and errors only on real use, so the worker
  degrades like the API instead of taking down the stack.
- Skip the Mongo connection entirely when MONGODB_URI is unset, removing a ~20s
  startup hang against the implicit localhost:27017 default.
- In local mode the backend rewrites agents' host.docker.internal ACP host to loopback
  (AGENTEX_ACP_HOST_OVERRIDE), so default-scaffolded agents work without manifest edits.

Also fix a frontend dev-server process leak in dev.sh (kill the whole make→npm→next
tree and sweep orphans; report status by listening port), correct the MongoDB and
OpenTelemetry install commands, and document local mode in README and CLAUDE.md.
@aringuyen3
aringuyen3 force-pushed the aringuyen/run-local-no-docker branch from 356b3eb to aa8bb61 Compare July 13, 2026 16:34
raw = acp_url_override

# Prefer the production deployment's URL when there's no explicit override.
if raw is None and agent.production_deployment_id:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smoreinis can you take a look here just make sure it doesn't conflict with the preview workflow?

"""
# In docker-free local mode, rewrite host.docker.internal -> the host-reachable
# override so the healthcheck matches how the request path dials the agent.
acp_url = resolve_acp_url(acp_url)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just making sure, no other places we need to do conversion right?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, only running this mode

if acp_url_override:
return acp_url_override
"""Resolve the ACP URL for an agent, optionally overriding with a specific URL.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did we lose the override?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi, so ./dev.sh no-docker will pass _ACP_HOST_OVERRIDE_ENV variable, so the function resolve_acp_url will resolve this. Besides this, the logic of this function is kept the same

Returns the URL unchanged when the override env var is unset or the URL does
not use the Docker sentinel host, so it is safe to call on every ACP dial.
"""
override = os.environ.get(_ACP_HOST_OVERRIDE_ENV)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this where the override moved?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, here we override the environment variable _ACP_HOST_OVERRIDE_ENV. This environment is set and passed from config.py file

Comment thread agentex/Makefile
# Development Server
#

dev: install-dev ## Start development server with Docker Compose

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are both technically local maybe rename to something more meaningful?

Comment thread CLAUDE.md

> **MongoDB is required for the full local stack** and is always started — the Temporal
> worker builds Mongo-backed repositories at startup, so a missing/unreachable Mongo
> makes the runner fail fast (with an install message) rather than crash the worker.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ty for adding here

@danielmillerp danielmillerp left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lots of small questions! also as far as testing on PC, not super sure. A lot of our clients do use PCs and I know there are Scaliens who have PCs. What problems do you anticipate?

@levilentz levilentz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this is rad.

One UX suggestion: in addition dev.sh, I think this would be really nice to have in the agentex CLI. I.E. you can run a single agent inline. therefore to start running a single agent you can start quick rather than having both the agentex backend and cli running. then this setup would be suitable for someone testing a multiagent flow.

Not sure if that is possible given the abstraction and integration, but wanted to throw it out there as a north star.

@danielmillerp

Copy link
Copy Markdown
Collaborator

Overall this is rad.

One UX suggestion: in addition dev.sh, I think this would be really nice to have in the agentex CLI. I.E. you can run a single agent inline. therefore to start running a single agent you can start quick rather than having both the agentex backend and cli running. then this setup would be suitable for someone testing a multiagent flow.

Not sure if that is possible given the abstraction and integration, but wanted to throw it out there as a north star.

+1 to that!

@aringuyen3

Copy link
Copy Markdown
Author

lots of small questions! also as far as testing on PC, not super sure. A lot of our clients do use PCs and I know there are Scaliens who have PCs. What problems do you anticipate?

@danielmillerp So Im testing this on Windows (via AWS Workspaces) but the embedded Redis uses (the redislite package has no native Windows build (Redis ships no supported Windows server) so the dependency required to run locally without Docker won't even install on native Windows.

Comment thread agentex/scripts/dev_nodocker/runner.py
@aringuyen3 aringuyen3 closed this Jul 17, 2026
@aringuyen3 aringuyen3 reopened this Jul 17, 2026
@aringuyen3

Copy link
Copy Markdown
Author

Some findings from testing local dev on Windows:

  • I'm testing running locally on native Windows, but the embedded Redis uses the redislite package, which has no native Windows build (Redis ships no supported Windows server). So the dependency required to run locally won't even install on native Windows.
  • Workarounds today: run dev locally with Docker, or use the Docker-free local mode inside WSL2.
  • Open question for FDE / customer environments: can they install WSL2 in their env? I wouldn't assume it's always available.
  • Worth noting: I use AWS Workspace, which doesn't support WSL2 — so even the WSL2 path isn't universal internally.

@NiteshDhanpal had a clear view on how to scope this. His take: don't treat Windows-native local mode as a hard requirement for now (given the redislite/Redis limitation), and use a support matrix instead:

  • Mac/Linux → Docker-free local mode
  • Windows with WSL2 allowed → Docker-free local mode inside WSL2
  • Windows without WSL2 / locked-down envs → Docker-based local dev

His main concern is a reliable fallback so customers aren't blocked when local setup is painful or impossible, and he thinks a cloud/dev-environment fallback is the most reliable option for that.

@danielmillerp

Copy link
Copy Markdown
Collaborator

Some findings from testing local dev on Windows:

  • I'm testing running locally on native Windows, but the embedded Redis uses the redislite package, which has no native Windows build (Redis ships no supported Windows server). So the dependency required to run locally won't even install on native Windows.
  • Workarounds today: run dev locally with Docker, or use the Docker-free local mode inside WSL2.
  • Open question for FDE / customer environments: can they install WSL2 in their env? I wouldn't assume it's always available.
  • Worth noting: I use AWS Workspace, which doesn't support WSL2 — so even the WSL2 path isn't universal internally.

@NiteshDhanpal had a clear view on how to scope this. His take: don't treat Windows-native local mode as a hard requirement for now (given the redislite/Redis limitation), and use a support matrix instead:

  • Mac/Linux → Docker-free local mode
  • Windows with WSL2 allowed → Docker-free local mode inside WSL2
  • Windows without WSL2 / locked-down envs → Docker-based local dev

His main concern is a reliable fallback so customers aren't blocked when local setup is painful or impossible, and he thinks a cloud/dev-environment fallback is the most reliable option for that.

I'm aligned @levilentz does that make sense for customers? Also CC: @lucyakoroleva for context per today's standup discussion

@levilentz

Copy link
Copy Markdown
Contributor

I'm aligned @levilentz does that make sense for customers? Also CC: @lucyakoroleva for context per today's standup discussion

@danielmillerp @aringuyen3 I think broadly this is a good first step. I think assuming that the customer will not have WSL or docker is the way to test this as that it normally the problem.

can we just disable redis in this mode?

@danielmillerp

Copy link
Copy Markdown
Collaborator

I'm aligned @levilentz does that make sense for customers? Also CC: @lucyakoroleva for context per today's standup discussion

@danielmillerp @aringuyen3 I think broadly this is a good first step. I think assuming that the customer will not have WSL or docker is the way to test this as that it normally the problem.

can we just disable redis in this mode?

I like that! not necessary to go from 0 to 1 to stream

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants