Skip to content
FlareX
Working with apps & bots

Deployments

How FlareX builds, deploys, and tails logs for your bot.

Updated

A deploy takes your bot's source at a specific version and turns it into a running container on a runner host. The process is queue-driven and observable at every stage.

Anatomy of a deploy

  1. Enqueue

    You click Deploy (or chat and accept a proposal). The API writes a Deployment row and enqueues a BullMQ job.

  2. Build

    A worker picks up the job, checks out the bot source, runs npm install --production --no-audit, and produces an OCI-compliant image layered on the bot-base image.

  3. Push

    The image is pushed to the runner selected by the bin-packing picker (CPU 40% + RAM 30% + load 25% + region 5%).

  4. Start

    The runner starts the container with the bot's secrets, resource caps (plan-specific), and a read-only filesystem. Dockerode polls for health.

  5. Live

    The Deployment row flips to live and logs start streaming via SSE. Previous live version is stopped and cleaned up.

Deploy logs

The log pane streams in real time. Each line is tagged with:

  • source: build / runtime / system
  • level: info / warn / error
  • timestamp: normalised to your browser timezone

Log retention depends on your plan (Starter 3 days, Pro 7 days, Enterprise 14 days; Free has no retained logs). Older logs archive to R2 and remain searchable via the per-bot history.

Tip

If you see the log stream pause for more than 10 seconds, it'll auto-reconnect — FlareX emits an explicit SSE retry: 5000 frame so browsers back off deterministically.

Rollback

Open the Deployments tab. You see a list of historical versions, each with:

  • Version number
  • Timestamp (in your timezone)
  • Commit-style summary from the chat proposal
  • Current state (live / previous / failed)

Click Deploy on any version to roll back. The runner picks a new host (might be the same), starts the old image, swaps traffic, and marks the current version as previous.

Rollbacks are typically 5–10 seconds because the image is already built and cached.

Failed deploys

If a deploy fails, the row is marked failed and the logs show why. Common causes:

  • Build: npm install fails due to a missing dep or a private registry token. Fix via Secrets or chat with FlareX to remove the dep.
  • Runtime: the container starts but crashes immediately. Logs usually contain the stack trace. Common culprit: missing DISCORD_BOT_TOKEN.
  • Health check: the container runs but doesn't bind the health port. FlareX kills it after the timeout and marks the deploy failed. Check that your bot doesn't crash silently at startup.
Failed deploys don't roll the live version back

Your previously-live bot keeps running. A failed deploy doesn't take production down — you stay on the last healthy version until you deploy a fix.

Concurrent deploys

Your plan has a deployConcurrency limit — the number of deploys that can run in parallel across your whole workspace. Free is 1, Starter 2, Pro 5, Enterprise 20. Additional deploys queue automatically and run FIFO.

Deploy blocked: past-due

If your Stripe subscription is past_due beyond the plan's dunning grace window (3 days Starter, 7 Pro, 14 Enterprise), new deploys are blocked. The existing bot keeps running. A banner explains the state and links to the Stripe customer portal.

Settle the invoice in the portal; the invoice.paid webhook flips your workspace back to active and deploys resume automatically.

Related

  • Runtime isolation — what runs inside the container
  • Databases — per-bot Postgres lifecycle during deploys
  • Billing — compute-second metering and past-due behaviour
PreviousSecretsNext3rd-party APIs — overview
Deployments · FlareX