Connic Dev Server: Test AI Agents in the Cloud Without Deploying

Connic Dev Server runs local agent projects in an isolated cloud development environment. The connic dev command uploads the project and synchronizes supported file changes, so a prompt edit can be tested with real model calls and connections without a Git push or a production deployment. The resulting runs are available in the dashboard for inspection.

What runs in the cloud?

Connic provisions a cloud runner for the development session. That runner executes the uploaded agents and Python code, including calls to models and external services. Local saves update the session; they do not require a release through the production deployment pipeline. The dashboard identifies the session with a Dev session badge on the Deployments page.

The Composer SDK introduction covered hot reload as one CLI capability. The full development workflow also includes persistent test configuration, on-demand test suites, and run inspection. The separate environments article covers branch-based releases to staging and production.

Start a development session

Start with a Connic project and local Composer files containing at least one valid agent in agents/. For a first project, the quickstart covers setup. From the local project root, install the SDK, authenticate, and start a named session:

pip install connic-composer-sdk
connic login
connic dev my-feature

Login saves project credentials to .connic. Keep that file in .gitignore; it is not part of the uploaded agent bundle. The CLI prints a dashboard link for the session's agents. Wait for the runner to be ready before triggering the first run.

Which local changes does connic dev synchronize?

The CLI watches the supported project directories recursively and bundles changes into an upload. Agent configuration is only part of that bundle:

agents/       # Agent YAML
tools/        # Python tools
middleware/   # Before and after middleware
hooks/        # Tool hooks
schemas/      # Output schemas
guardrails/   # Custom guardrails
tests/        # Test suites and supporting files

Once synchronization finishes, subsequent runs use the changed files. Saving a prompt does not itself start another agent run.

In an interactive terminal that supports the single-key controls, r forces an upload, t starts the test suites, and q stops the session. The Dev Server documentation provides the command and configuration reference.

Choose an ephemeral or named environment

An ephemeral environment starts fresh and is removed during normal session cleanup. A named environment retains its configuration for the next session, which is useful when a feature needs the same test credentials and connection setup across several edits.

Both modes use a development environment separate from standard environments. New dev environments do not automatically copy production variables or connections. Select the dev environment in the dashboard and configure the values and connections needed for the test. For example, a webhook connection created there can trigger the uploaded agent through its own endpoint.

Variables are loaded when the runner starts. After adding or changing variables in a named environment, stop the session and rerun connic dev my-feature so the runner receives the new values. The same sequence works when configuring a named environment for the first time.

A Python tool using live credentials can still write to a live external system. Use test accounts, sandbox endpoints, and appropriate credentials for those calls. Model-provider API keys configured on the project are shared with the dev runner; environment variables and connection configuration are scoped to the selected environment. The environment documentation explains how to manage that configuration.

Change a prompt, rerun the agent, inspect the trace

A prompt change provides a small, repeatable way to check the whole workflow. For an existing agent named assistant, keep the model and tools configured and change only its system_prompt. This excerpt sets a response constraint that can be checked after the next run:

system_prompt: |
  Answer the request in no more than three sentences.
  If information needed to answer is missing, ask for it.

1. Run the agent once from the session's dashboard link to establish a baseline.
2. Save the prompt edit locally, wait for the CLI to report the upload, and allow the cloud runner to reload the project.
3. Trigger the agent again with the same input in the selected dev environment.
4. Open the new run and expand its model span to inspect the input and response.

A span represents an operation within a run. Tool spans show arguments and results; middleware spans show the work around the agent call. The dashboard updates active runs as execution progresses. Compare the response with the earlier run and check whether it meets the intended constraint.

To test event delivery as well, trigger a connection configured in the dev environment and open its resulting run. That exercises the connection and the uploaded agent together. The runs and traces guide explains the trace view and individual span types.

Run tests against the active dev environment

Test files synchronize with the project, but saving them does not automatically run the suites. After synchronization, press t in the dev terminal to run the suites from tests/ against that session's environment. The results include a dashboard link for further inspection. Test execution builds an image from the uploaded project and starts a separate test runner, so it has its own startup step beyond the interactive hot reload.

From a second terminal, target the dev environment explicitly. Replace the placeholder below with its environment ID:

connic test --env <dev-environment-id>

Bare connic test uses the default standard environment's configured test environment, or the default standard environment itself. It does not select the running dev session automatically. The test execution reference covers environment selection and filtering; the testing framework article covers writing the cases.

Handle dependencies, conflicts, and cleanup

Dependencies in requirements.txt are installed during session startup. Changing that file during an active session causes subsequent uploads with the changed requirements to be rejected. Stop the session and start it again to install the new dependencies. Dev Server accepts simple package requirements with binary distributions; local-path and Git dependencies are not supported by this installation step. For a named environment, rerun connic dev my-feature to keep the existing variables and connections.

Only one dev session can be active for a named environment. If the name is already in use, stop the existing session in its terminal, choose a different name, or use an ephemeral session. Separate names let developers work on different changes in the same project, within its active-session limit.

Press q, or Ctrl+C when single-key controls are unavailable, to stop deliberately. Normal cleanup stops the runner and removes an ephemeral environment from use, including its connections. Named environments remain available for a later session, but their stopped runners do not continue serving agents. Background cleanup also handles inactive sessions and retries failed infrastructure cleanup. Infrastructure cleanup can remain pending if teardown fails.

For an existing project, follow the Dev Server setup and start a session from the local project root.