MeshAgent 0.42 focuses on project, service, and deploy workflows. Projects can now be looked up by key, services and routes can include host ports and route prefix behavior, container and build APIs expose richer inspection details, and deploys now recognize authenticated liveness responses and use resolved image digests after completed builds.
Projects now have a stable project_key alongside their generated IDs, and SDK clients can look up a project by that key.
In practice, this makes project-oriented workflows easier to wire into CLI commands, SDK clients, and deployment configuration. A project can still be identified by ID, but users and tools now have a supported lookup path for the key that appears in project metadata.
Service and route definitions now carry more of the details that matter when a room service is actually running. Service and route specs now carry the container template setting, container creation and room-client helpers accept it, port specs can include host_port, and route paths can use stripPrefix to control whether a matched route prefix is forwarded to the backend service.
A service can request the MeshAgent agent runtime defaults through a template, ask for a stable host-side port when needed, and define whether the external route path should be preserved or stripped before the request reaches the container.
This release also changes container listing responses to use structured containerPort and hostPort pairs instead of bare integer port lists. That is a breaking response-shape change for clients that parse container listings directly, but it gives applications the information they need to distinguish the port inside the container from the port exposed by the room.
Container and build models now expose image IDs, runtime stats, published build image metadata, and detailed exit status information. SDKs also add waitForExitStatus or wait_for_exit_status alongside the existing waitForExit helpers, so callers can keep the simple exit-code path or inspect the fuller status when they need it.
For teams operating room services, this gives better answers to basic runtime questions: which image ran, which digest was published, what stats are available for the container, and why did it exit. That makes custom dashboards, developer consoles, and deploy tooling easier to build.
The deploy flow now treats 401 and 403 responses as evidence that a protected endpoint is live. That is important for private services where a healthy route may reject an unauthenticated liveness probe instead of returning 200.
Deploy log handling also improves. The deploy TUI can copy selected text or the full log buffer, and background log/progress tasks are cancelled cleanly when the deploy view exits. When a build completes, the deploy flow resolves the published digest, rewrites the deploy plan to use that resolved image reference, and cleans up replaced built images after successful deploys.
Together, those changes mean an authenticated service can report live without returning a public 200, and a build-based deploy records the resolved image reference that was applied.
Taken together, MeshAgent 0.42 makes projects easier to identify, service runtime behavior easier to model, container state easier to inspect, and deploys easier to operate.
Join our Discord community to keep up with MeshAgent releases, ask questions, and share feedback with the team.
Check out the MeshAgent documentation to start building today.
MeshAgent Studio, SDK, and Server give you everything to build, test, and deploy agentic applications, from development to production.
