How to Set Up Development and Production Environments in Make.com
If you have been building automation in Make.com for any length of time, you will probably recognise this moment.
A small change seems harmless. You tweak a scenario to handle a new edge case, save it, and move on. A few hours later, an order fails to process, a customer is confused, or a finance reconciliation no longer balances. The change “shouldn’t” have caused that — but it did.
For many small and growing teams, this is the point where automation stops feeling empowering and starts feeling fragile.
Tools like Make.com and Adobe Fusion make it possible to build sophisticated integrations quickly, without a full engineering team. That speed is their strength. It is also where most of the risk creeps in.
As automation becomes central to operations — handling orders, payments, reporting, customer communications — the absence of clear development, test, and production environments becomes harder to ignore. This article explains why that happens, why it matters, and how to approach the problem in a way that is proportionate, practical, and robust.
The core problem: low-code tools do not enforce environments
In traditional software engineering, the idea of separate development, test, and production environments is well understood. Changes are built somewhere safe, validated in isolation, and only then released into live systems.
Low-code automation platforms rarely enforce this model.
In Make.com, a scenario is both the design artefact and the running system. The same visual flow you edit in the browser is often the one moving real money, real data, and real customer communications.
This leads to two common assumptions:
-
“We’ll just be careful.”
Care does not scale. It is not a control mechanism. -
“We’ll duplicate the scenario when we need to test.”
Duplication is not the same as having environments. In practice, it often increases confusion.
SME context
In small businesses, automation often starts with a single builder. Early on, this works well. Changes are infrequent, volume is manageable, and the system lives mostly in one person’s head.
Over time, that same scenario may:
-
Handle multiple product lines
-
Integrate with several third-party systems
-
Contain business rules that are no longer obvious from the visual layout
At that point, testing changes directly in the live scenario becomes a gamble — but there is no obvious alternative.
Enterprise context
In larger organisations, the risk looks different but stems from the same root cause. Multiple people may touch automation. Changes need coordination, review, and traceability.
Without explicit environments, teams fall back on informal rules and conventions. These are brittle, undocumented, and heavily dependent on tribal knowledge.
Why this becomes a bigger issue over time
Automation failures are rarely dramatic at first. They compound quietly.
Scale increases the blast radius
When a scenario runs once a day, a mistake is irritating. When it runs every minute, the same mistake can affect hundreds or thousands of records before anyone notices.
Frequency reduces tolerance for error.
Teams grow, context shrinks
As soon as more than one person is involved, assumptions diverge. Someone changes a filter, not realising another module depends on its current behaviour. Credentials are rotated. A “temporary” workaround becomes permanent.
Without clear separation between safe experimentation and live operations, every change carries hidden risk.
Business reliance hardens expectations
The most dangerous automations are not the experimental ones. They are the quiet, reliable scenarios that have been running for months.
When those fail, the impact is immediate: cash flow disruption, customer trust erosion, compliance exposure. At that point, the conversation shifts from speed to reliability.
Practical ways to approach dev, test, and prod in Make.com
There is no single “correct” setup. The right approach depends on business criticality, team size, and appetite for risk.
What follows are principles and frameworks rather than implementation scripts.
Think in environments, not scenarios
An environment is not just a copy of a scenario. It is a context.
Conceptually, environments allow you to:
-
Change logic without touching live operations
-
Test with realistic but non-critical data
-
Promote changes deliberately rather than accidentally
In Make.com, environments are something you model, not something the platform hands you by default. How you do that matters less than being explicit that they exist.
A blunt but effective way to create environments
If you want a clear, workable definition of dev and prod in Make.com, the most reliable starting point is this:
Use separate teams as separate environments.
It is not elegant. It is effective.
Using teams as environments
In this model, you create:
-
One team for development
-
One team for production
Each team has its own scenarios, connections, and configuration. The production team is treated as stable and protected. Development is where change happens.
The key enabler is the disciplined use of custom variables for anything that differs between environments, such as:
-
API base URLs
-
Webhook endpoints
-
System identifiers
-
Feature flags or mode switches
The scenario logic stays the same. Environment-specific behaviour is injected via configuration.
How this works conceptually
The flow, at a high level, looks like this:
-
Build and modify scenarios in the dev team
-
Test end-to-end using dev data and credentials
-
Copy the scenario into the prod team
-
Production variables are applied
-
Enable the scenario in production
This gives you three important outcomes:
-
You can change behaviour without touching live operations
-
You can test realistically rather than hypothetically
-
Production stability depends on configuration, not hope
For many teams, this is the first point at which automation starts to feel controllable rather than fragile.
The limitation: manual promotion
The weakness is obvious.
Manually copying scenarios:
-
Takes time
-
Encourages last-minute “small fixes” in production
-
Creates drift between environments
-
Relies on human discipline at exactly the wrong moment
At low volume, this may be acceptable. As automation becomes more central — or more people are involved — it becomes a genuine operational risk.
The more robust evolution
The natural next step is to automate the promotion from development into production.
Instead of copying scenarios by hand, changes are pushed deliberately from dev to prod, with production variables injected as part of that process. This restores a fundamental property that traditional engineering teams rely on: the same artefact moves through environments.
The mechanics of doing this well are non-trivial and depend heavily on context. This is also the point where governance, review, and versioning start to matter in a more formal way.
The key principle is simple:
Production should only ever receive changes that have already been tested elsewhere.
Common mistakes teams make
-
Testing directly in production
This is the default behaviour — not a best practice. -
Relying on copy-paste alone
Duplication without discipline leads to drift. -
Over-engineering too early
Importing full enterprise patterns into small systems adds cost without reducing risk. -
Treating automation as “set and forget”
Automation is software. Software requires maintenance. -
No clear ownership
If everyone can change everything, accountability disappears.
Conclusion
Low-code platforms are powerful precisely because they remove friction. The challenge is that friction often exists for a reason.
Setting up meaningful dev, test, and production environments in Make.com is not about copying enterprise engineering wholesale. It is about recognising when automation has become operationally critical — and treating it accordingly.
A small amount of structure, introduced at the right time, dramatically reduces risk without slowing teams down.
If you are running automation at scale and finding this challenging, it is worth stepping back and introducing structure deliberately rather than reactively.
I help teams reduce workflow failures, improve delivery confidence, and scale automation safely with practical governance, clearer change control, and production-ready low-code systems.