Can I use Novamira on a live/production site?

Short answer

The plugin can be installed anywhere. AI abilities should only be activated on development and staging sites, never on production. The risk on production isn’t the plugin itself, it’s the workflow. This applies equally to Novamira and Novamira Pro.

Keeping the plugin installed on a live site

Novamira and any sandbox files an agent built in staging travel to production with your normal deploy, the same way any plugin or theme does. This is fine, and sometimes intentional: sandbox files only execute through Novamira’s loader, so for AI-built features to run on the live site, the plugin has to be there to load them.

On production, just leave Novamira active and keep AI abilities off. Authentication for AI access is strict (HTTPS, WordPress Application Passwords, admin users only), and with abilities off no AI client can connect through the plugin. The loader runs what came from staging; no AI access path to the live site is ever open.

What matters is the next step: do not turn AI abilities on for a production site.

Why not activate AI abilities on production

The plugin is the same on every site. The reason to keep AI abilities off in production is workflow, not safety.

When AI abilities are active, your AI agent can reach into that site through MCP. If you had configured both your staging site and your production site as separate MCP servers in your AI client, it would be very easy to point the agent at the wrong one. A misnamed prompt, a stale tab, a moment of confusion between two similar conversations, and the agent could run PHP, edit a file, or change a database row on the live site you didn’t mean to touch.

Novamira gives the AI runtime access on purpose. That power is the value. But that same power means the only safety net against pointing at the wrong site is you, paying attention. Production is exactly the environment where you don’t want a single moment of distraction to matter.

Keep AI abilities on for staging, development, and local sites. Keep them off everywhere else.

AI abilities are tied to the domain

AI abilities are locked to the domain where you activated them. If you clone or restore a site onto a different domain, the abilities do not carry over: they have to be reactivated explicitly on the new domain.

There is also a separate, client-side layer. Your AI client connects to a specific Novamira site through MCP, configured manually with the site’s URL and an Application Password. Cloning a WordPress database doesn’t reconfigure your AI client. The client only reaches sites you have explicitly added as MCP servers.

This means you cannot end up with the agent acting on production by copying a database from staging. Both ends, WordPress and the AI client, have to be set up deliberately for that site. So you can deploy or clone from staging to production with confidence: AI abilities don’t follow.

The agent’s changes are real

Whatever the agent writes through Novamira, whether a PHP file in wp-content/novamira-sandbox/, an edit to an existing theme or plugin file, or a database change, lands as a real change on the site. There is no separate layer that holds AI work apart for you to approve later.

Files in your codebase travel with your next deploy if your deploy process picks them up. Database changes stay on the site where they happened. Nothing rolls back automatically.

This is the deeper reason staging is the right place for Novamira. Whatever the agent made is for you to review there before it goes anywhere else: keep it, refine it, ship it, or throw it away. Production is for results that have already passed that review, not for doing the work.

There is no read-only mode

Novamira does not offer a read-only mode. AI abilities are either on (full read and write through the sandbox and execute-php) or off. There is no middle ground.

If you need to investigate something that only happens on production, pull a snapshot to staging and reproduce it there. Let the agent work on the staging copy.