Running Bricklayer near production: what to disable and why

Just enough hardening to run Bricklayer on staging or production without handing an AI agent the keys to the store.

The default answer is: don’t. Install Bricklayer with composer require --dev, and a production deploy with composer install --no-dev will not even have it. Most of the value is in development anyway.

But sometimes You need runtime answers from the real thing. A production-only bug, a staging copy with real data, a performance problem that does not reproduce locally. For those cases Bricklayer has a production mode built in.

When Magento runs in production deploy mode, Bricklayer does this on its own:

  • code-runner is hard-blocked, no config can enable it
  • destructive tools are blocked unless .bricklayer.json explicitly says "enabled": true: product-delete, category-delete, customer-delete, customer-address-delete, order-cancel, creditmemo-create
  • all 4 generate-* tools refuse to write files unless explicitly enabled
  • bricklayer init generates production defaults: 12 tools disabled, database-query.max_rows lowered to 50
  • no config file or no entry for a destructive tool means blocked, not allowed

What to disable and why

The built-in protection is a floor, not the recommended config. The README goes further:

{
    "tools": {
        "code-runner": { "enabled": false },
        "database-query": { "enabled": false },
        "product-delete": { "enabled": false },
        "customer-delete": { "enabled": false },
        "category-delete": { "enabled": false },
        "generate-module": { "enabled": false },
        "generate-model": { "enabled": false },
        "generate-controller": { "enabled": false },
        "generate-api": { "enabled": false }
    }
}
Tool Why off
code-runner arbitrary PHP inside the live app; blocked anyway, keep the file honest
database-query read-only and masked, but raw SELECTs on customer and order tables are still personal data in an AI context
*-delete irreversible, there is no undo for a deleted customer
generate-* code does not get written on production, it gets deployed

What stays useful on production: diagnose-error, diagnose-performance, system-status, log, check-class, plugin-list, layout-inspect and the rest of the introspection tools. They read the merged runtime state, which is exactly what You can not reproduce locally.

Think about the order, customer and catalog write tools too. product-update, order-hold, customer-update… are enabled by default even in production. If the agent should only look, switch them off one by one with config:set. 26 write tools in total can be toggled individually.

Built in, whatever the config:

  • database-query is SELECT only, with automatic LIMIT and validated table names
  • payment/*, carriers/*, oauth/* and similar config values are masked in results

Checklist

  1. Confirm the deploy mode Bricklayer sees: vendor/bin/bricklayer inspect or system-status check="deploy-mode"
  2. Generate production defaults: vendor/bin/bricklayer init --force
  3. Apply the recommended config above, plus any write tools You want off
  4. Pin critical switches with env variables in the server environment, they override the file:
BRICKLAYER_TOOLS_DATABASE_QUERY_ENABLED=false
BRICKLAYER_TOOLS_PRODUCT_UPDATE_ENABLED=false
  1. vendor/bin/bricklayer verify - checks .bricklayer.json is valid
  2. Do not commit the production .bricklayer.json over the development one. Keep it on the server, or use env variables only
  • Prefer a staging copy with production-like data over production itself
  • Done debugging? Remove it: composer remove inchoo/magento-bricklayer, no database cleanup needed

Start coding! Carefully.

Source: GitHub