Skip to content
    monk.io
    Get startedStart

    Let the team move.
    Keep the boundaries.

    Give developers an operations workflow inside their coding agent. Your team controls access, reviews consequential changes and defines what can recover automatically.

    Talk through your requirementsSecurity & Control

    One system to inspect.
    Clear authority to act.

    The agent works with Monk’s application model. Operations pass through the orchestrator, where permissions and validation apply independently of the conversation.

    Monk’s application graphVite frontend, Node.js API and Go workers, with shared Redis, MongoDB, Stripe, Auth0 and object storage dependencies. Services are contained in containers and cloud machines, with frontend and API ingress, load balancing, DNS, volumes and backups. Workers connect to the queue directly. Arrows show connections; moving dashes show example data flow. The selected resources are emphasized as the system changes.DigitalOceanAmsterdam · your accountMongoDB AtlasManaged dataDroplet 012 vCPU · 4 GBDroplet 022 vCPU · 4 GBDroplet 032 vCPU · 4 GBContainerContainerContainerDroplet 04ContainerFrontendVite · web appAPINode.jsWorkersGo · background jobsDatabaseMongoDBJob queueRedisAuth0AuthenticationStripePaymentsIngressIngressLoad balancerHTTPS · 443app.example.comCloudflare · DNSAPI volume20 GB · block storageWeb volume10 GB · block storageObject storageDigitalOcean SpacesDaily backupAtlas · daily snapshot
    Drag to explore
    API / stdout
    14:32:10INFOGET /tasks200 12ms14:32:11INFOPOST /exports202 8ms14:32:12INFOqueue.publishexport-4214:32:13INFOworker.connectedworker-0314:32:14INFOdb.query18 rows 4ms14:32:15INFOGET /health200 1ms14:32:16INFOauth.verifysession valid14:32:17INFOGET /tasks/42200 6ms14:32:18INFOstorage.putexport-42.csv14:32:19INFOexport.complete1.8s 240KB14:32:20INFOGET /exports/42200 3ms14:32:21INFOqueue.ackexport-4214:32:22INFOPOST /tasks201 9ms14:32:23INFOcache.hittasks:list14:32:24INFOGET /tasks200 2ms14:32:25INFOGET /health200 1ms
    Example stream · read-only
    01 / 05Read the API logs

    Select the API and follow its output without losing its place in the system.

    Read the diagram, step by step

    1. Read the API logs

      Select the API and follow its output without losing its place in the system.

    2. Scale the workers

      One worker becomes three. The container expands around the stack; the dependencies stay attached.

    3. Add a VM

      The same cloud gains a machine. Two of the three workers move onto it, sharing the existing queue and services.

    4. Rotate the Stripe key

      Rotate the credential, then notify the API and every worker that depends on it. The value stays hidden.

    5. Back up the database

      The database stays in place. A new snapshot appears beside it in Atlas.

    Your team sets the rules.

    Cloud ownership

    Resources run in your account. Choose provider credentials, environments and regions. Enter secrets through Monk’s credential forms.

    Access and approvals

    Roles and assignments determine who can operate which resources. Review deployment plans, warnings and costs before approving them.

    Recovery policy

    The orchestrator can restart or reschedule workloads within configured policies. Watcher’s AI diagnosis proposes a fix; applying that remediation requires approval.

    Operating history

    Inspect the team’s action history to understand what ran and under whose authority. Confirm retention and audit requirements against your plan.

    Evaluate alongside
    what already works.

    Use a separate environment to prove the workflow. Keep the original deployment under its existing owner until you decide to transfer data and traffic.

    1. Deploy a representative app

      Start from the repository. Check the database, workers, secrets and external dependencies, then exercise a real application transaction.

    2. Test the boundaries

      Review a change, test a denied operation and open a fresh agent session. Verify that state, permissions and approvals behave as your team expects.

    3. Test recovery and the exit

      Simulate a failure within your evaluation environment. Review backups, recovery objectives and the work required to take over operations later.

    Before a wider rollout.

    Match the operating model to your organization’s requirements, including identity, support and audit retention.

    Compare with Terraform
    Can Terraform keep managing production?

    Yes. Keep the original deployment under its existing owner while evaluating a separate Monk environment. Avoid assigning the same resource to two infrastructure controllers.

    What does leaving Monk involve?

    Your cloud account remains yours. Taking over operations still means replacing resource lifecycle, service connections, deployment and recovery. Plan the handover of configuration, credentials and data before stopping the controller.

    How do we evaluate team requirements?

    Test roles, assignments and environments with a representative workflow. Confirm identity-provider integration, audit retention, support and contractual requirements with Monk before rollout.

    Start with one application.

    Prove the deployment, change and recovery workflow before expanding access.

    Bring an existing app Start a new app