We have a question about workspace safety / backups / scaling governance.
We have already built and are continuing to build a Fibery workspace for one part of our team. Now we are thinking about connecting another similar team to the same workspace.
A single shared workspace would be much more convenient for us, but there is one concern: the second team originally chose a more “vibe-coding” / experimental approach, and we can’t be fully sure that they won’t accidentally break something important in the shared system.
So we are thinking about what the safest and most practical setup could be.
Has anyone already solved something like this in a rational way?
Options we considered:
Separate backup workspace
Periodically copy important schema/data there via automations, so we have some kind of restore/reference environment.
Periodic workspace export / documentation
Regularly export or document schema, databases, relations, automations, etc. — possibly with the help of Claude/MCP or API.
Separate production and experimental areas
Keep the main workspace stable, while allowing the second team to experiment only in isolated spaces first.
The main question is:
What is the best way to protect a growing Fibery workspace when multiple teams and builders start working inside it?
We are especially interested in:
backup / restore strategies
schema change safety
protecting production workflows
preventing accidental damage from experiments
practical approaches used by larger teams
Would appreciate any experience or recommendations
If the dbs that the different teams are working on are not highly coupled/interdependent, then judicious use of access control can help stop one team from messing up another team’s work (e.g. not giving admin rights out too freely, but rely on space/database-limited architects).
Backing up and then restoring the schema is likely to be quite challenging, however you approach it (it’s a long story, but you can probably envisage situations where things get really messed up). Much easier to prevent breakages, rather than relying on a recovery system.
Otherwise, consider using policies external to Fibery to limit the risks arising from dependencies, e.g. enforcing Descriptions for fields that describe how they are used and why, plus whether or not they can be relied upon (= stable vs experimental).
Apart from that, I too will be interested to hear what others recommend.
A few of the approaches we are currently planning are:
Extremely limited number of Admin accounts.
Script-based automations are treated as controlled changes — only reviewed/approved by Admins scripts are allowed, and only Admins can actually apply those changes.
Separate technical accounts for external automations (n8n, integrations, etc.). The new webhook actions in automations should help a lot here by reducing the need to give broader access inside Fibery.
Disabling Fibery AI at the workspace level, so AI does not have access to sensitive areas such as financial data. Instead, using Claude via MCP connected through dedicated technical accounts that only have access to specific databases.
Extensive documentation for databases, fields, automations, and dependencies.
Automated backups of schema and workspace structure. Or maybe backup workspace
We’re still refining the approach, but at the moment we’re leaning much more toward prevention, governance, and isolation rather than relying on recovery after something breaks.
And yes — we completely agree that preventing problems is much easier than recovering from them, and we are planning to invest heavily in that direction .
At the same time, from a corporate governance and risk-management perspective, there still needs to be a Plan B .
We also considered Fibery-to-Fibery Sync, but unfortunately it is primarily one-way synchronization . Our challenge is not really data replication — it is allowing multiple teams to work safely on the same operational system while minimizing the risk of accidental changes to production structures and workflows.
.