Environment Firewall (FULLFINITY_ENV)

Every instance runs as one of three environments, set by the FULLFINITY_ENV process variable:

• production — live. Real emails, messages, push, payments, and scheduled jobs all run.
• staging / test — firewalled. Outbound side effects are suppressed so the instance cannot touch real customers.

This is an engine guarantee, not a per-instance checklist: a staging or test copy of a production database physically cannot email a customer, because the block lives at the framework’s outbound choke points. It defaults to production, so an instance behaves live only when explicitly told it is production.

What is suppressed in a firewalled environment

• All outbound messaging — email, SMS, and other channels are dropped at the single messaging delivery point. The message is recorded as sent but nothing is transmitted.
• Web push notifications.
• Scheduled jobs (crons) are paused, so nothing re-triggers the effects above.

Reads, the UI, and everything internal continue to work normally — only outbound, real-world effects are blocked.

Guarding your own outbound effect

If your module performs its own real-world side effect that isn’t already routed through the messaging or push layers — charging a card, calling an external webhook, hitting a third-party API that mutates real data — guard it the same way:

from fullfinity.engine.environment import is_firewalled

async def charge_card(self, amount):
    if is_firewalled():
        return  # never charge in a non-production environment
    ...

is_firewalled() is true in staging and test; is_production() is its inverse. Use them so a cloned environment of a customer’s data can be experimented on safely — the whole point of a staging or test environment is that it can run risky changes without real consequences.