Skip to content
    monk.io
    Get startedStart

    Keep a small team’s app running.

    Read logs, scale services and review changes from your coding agent. The orchestrator handles configured recovery; Watcher investigates problems that need a reviewed fix.

    Bring an existing appSee the workflow

    Work on the system you actually have.

    A deployment is the beginning. Services need inspection, workers need capacity and failures need attention. Monk connects each request to the running application, its dependencies and its infrastructure.

    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.

    A workflow your team can keep.

    1. Establish a separate deployment

      For an existing app, begin with fresh infrastructure from the repository. Verify the app alongside the original. Plan data transfer and cutover separately before relying on the new environment.

    2. Recover within the policy

      When a Monk-managed workload exits or its host fails, the orchestrator can restart or reschedule it under its recovery policy. Retry limits, available capacity and workload configuration determine what can recover.

    3. Review a fix for persistent problems

      Watcher uses system signals to diagnose an issue and propose a response. Review and approve its remediation. Use the resulting status and logs to check whether the issue is resolved.

    Recovery has two layers.

    Automatic workload recovery is different from AI remediation. A failed HTTP health check alone does not guarantee a restart. Managed cloud services also have their own recovery behavior. Your team still owns application correctness, backups, recovery objectives and incident decisions.

    Does Watcher fix everything without me?

    No. Watcher’s AI diagnosis leads to a proposed remediation that requires approval. The orchestrator’s configured workload recovery can act automatically without waiting for that AI workflow.

    Can Monk start watching my current production estate?

    The default adoption path rebuilds infrastructure from your codebase in a separate environment. It leaves your existing deployment untouched. It is not an automatic takeover of arbitrary running infrastructure.

    What happens when the chat ends?

    The orchestrator maintains its system state independently of the coding conversation. In a new session, ask Monk for current services, status and logs. Watcher availability depends on your plan and setup.

    Try it with your application.

    Start from your repository. Review the resources and costs before you deploy.

    Bring an existing app Start a new app