Skip to main content

​
Overview

MeshAgent exposes image workflows through meshagent build and meshagent deploy. Use these commands when you want to:
  • build and publish an image from a local directory inside a room
  • deploy an image directly as a room service
This command is useful both for developers working from the CLI and for agent workflows running inside a room. It gives MeshAgent a room-native way to build, package, and ship images without requiring Docker on the local machine that triggers the workflow.

​
How image commands fit into MeshAgent

These commands sit between source files and a deployable MeshAgent service:
  1. meshagent build builds an image inside a room using a local PATH.
  2. meshagent deploy creates or updates a room service from that image.
This complements the normal service packaging flow. In practice, a room-connected agent can:
  • prepare files in the room
  • build an image from those files inside the room
  • deploy a service that uses that image
That makes these image commands especially useful for workflows where an agent is expected to build, test, and ship a containerized service for you from inside MeshAgent.

​
Commands

​
meshagent build

Use build when you want MeshAgent to build an image inside a room. The build context can come from:
  • room storage mounts
  • project storage mounts
  • mounted images
  • a packed local directory passed as the positional PATH
If the packed directory contains a Dockerfile, MeshAgent can use that Dockerfile during the room-side build. This means the build runs in MeshAgent rather than requiring a local Docker daemon on the machine that started the command. Example using a packed local directory: 
meshagent build ./my-app \
  --room myroom \
  --tag registry.meshagent.com/myproject/my-app:dev
Key things to know:
  • --tag is required
  • --room is required unless MESHAGENT_ROOM is already set
  • PATH uploads a local directory to room storage and mounts it for the build
  • local PATH builds accept shorthand registry tags like <repository>:<tag>
  • build logs stream back through the CLI while the build runs
  • this is a good fit for agent-driven build workflows inside a room because the build happens in MeshAgent, not on the local machine

​
meshagent deploy

Use deploy when you already have an image and want to create or update a room service from it. Example: 
meshagent deploy \
  --room myroom \
  --tag registry.meshagent.com/myproject/my-app:dev \
  --env APP_ENV=dev
You can also build from a local directory and deploy in one step: 
meshagent deploy ./my-app \
  --room myroom \
  --tag registry.meshagent.com/myproject/my-app:dev
You can also:
  • mount room storage with --room-mount
  • mount project storage with --project-mount
  • mount another image with --image-mount
  • inject a MESHAGENT_TOKEN with --meshagent-token
  • override the deploy identity for --meshagent-token and --env-secret with --identity
  • inject a secret-backed environment variable with --env-secret NAME=SECRET_ID
  • publish a route with --domain when the service exposes exactly one published port
This command derives the service name from the image tag and updates the existing room service when one already exists.

​
How image builds and deploys work with service packaging

The image commands and service packaging are complementary. Use these image commands when:
  • your workflow is image-first
  • you want to build inside a room
  • you want to build from a local directory inside a room
  • you want a fast path from image tag to room service
  • you want an agent in the room to participate in building and shipping the service
Use the service packaging docs when:
  • you are writing or reviewing a meshagent.yaml
  • you need a fuller service spec with more explicit deployment structure
  • you are working with ServiceTemplates or broader service configuration
In other words, these commands are the room-native image workflow, while service manifests are the broader service-definition workflow.