How To Build A Scalable Package Management Framework

Introduction

If you’ve built anything serious with Site Studio, you’ve probably hit this wall:

• Your layouts work. Your components are clean. But your configuration syncs are a mess.
• Teams export overlapping packages.
• Local environments drift from staging.
• Custom styles vanish during deployment.
• And deleting a single component triggers a fire drill across three environments.

We’ve been there.

In a recent multi-brand DXP rollout, our Site Studio setup started collapsing under its own weight. The problem wasn’t in the components; it was in how they were being packaged, reused, and governed.

So we built a Site Studio Package Management Framework, a systematic approach to keep configuration lean, clean, and scalable. This blog walks through that use case and what we learned solving the exact problem you might be wrestling with today.

The Problem: When Scaling Site Studio Becomes a Liability

Site Studio promises agility. It gives marketers control and accelerates layout creation. But it comes with an often-overlooked cost: configuration fragility.

Here’s what broke for us as we scaled:

• Redundant Exports: Developers included the same config in multiple packages without realizing it
• Cross-Package Contamination: Updating one component caused unintended changes elsewhere
• Failed Imports: Environment syncs broke when config dependencies weren’t properly scoped
• Manual Deletions: Removing a custom style required hands-on cleanup in every environment
• Non-Reusable Config: Custom components couldn’t be ported cleanly to new brand instances
  
  

These issues weren’t about development quality; they were about governance gaps.

Site Studio didn’t break because it’s weak. It broke because we were asking it to scale without a system.

The Use Case: Governing A Multi-Brand Drupal Platform With Site Studio

The platform in question supported multiple branded microsites, each with its own style guide, layout rules, and editorial workflows. The client expected to:

• Launch new brand sites quickly, using existing components
• Maintain strict environment parity from Dev to QA to Prod
• Avoid regression bugs caused by misaligned configurations

But Site Studio’s default export/import flow wasn’t designed for that. There was no versioning system, no guardrails for duplication, and no structure for organizing the growing library of layout components and styles.

We realized that without a repeatable packaging model, Site Studio would become the bottleneck.

So the Axelerant team built one.

The Framework, Deep-Dived

To bring order and predictability to Site Studio’s powerful but complex configuration system, we established a set of disciplined practices, each addressing a critical pain point from packaging to synchronization.

1. Define Clear Package Boundaries

Why it matters: Site Studio allows developers to export any configuration into packages, but without structure, this leads to bloated, overlapping, and conflicting packages that are hard to maintain or debug.

What we implemented: We enforced a strict policy: every package must represent a single configuration category, not a feature or page.

Examples:

• pack_master_templates: For all master layout templates
• pack_hero_components: For hero-specific layout and style configuration
• pack_custom_styles: For global style definitions and design tokens
• pack_website_settings: For Site Studio settings like breakpoints or responsive rules
• pack_component_categories: For defining and managing reusable component types

Result: This structure created predictable configuration boundaries, helped identify ownership across teams, and dramatically reduced cross-package conflicts during exports and imports.

2. Standardize The Export Process With CLI + UI Discipline

Why it matters: Exporting through UI alone is error-prone. Site Studio often includes unnecessary dependencies that sneak into packages unless carefully reviewed.

What we implemented:

• Developers were trained to build packages in the UI while unchecking irrelevant dependencies
• CLI was used to export the finalized package cleanly:

ddev drush sitestudio:package:export --package=pack_hero_components --path=../config/site_studio_sync/pack_hero_components

Result: Cleaner exports, fewer merge conflicts, and smaller, more manageable configuration diffs.

3. Import With Precision: Multi-Package Coordination

Why it matters: Site Studio doesn’t track dependencies across packages. Without a controlled import structure, missing configs or incorrect order can break deployments.

What we implemented: We created a unified site_studio.packages.yml file to declare all available packages and control their import order.

Then we ran:

ddev drush sitestudio:package:multi-import --path=config/site_studio_sync/site_studio.packages.yml

Result: We eliminated "works on local, fails on staging" issues and ensured consistent environment parity across dev, QA, and production.

4. Govern Deletions: Manual Cleanup Protocol

Why it matters: Deleting configuration via code does not automatically remove it from Site Studio’s UI. This often leaves orphaned styles, components, or settings that continue to load, or worse, partially apply.

What we implemented:

• Developers must first delete unwanted styles or components in the UI
  
• Then rebuild and export the affected package
• Finally, manually verify and clean up on all downstream environments

Result: We avoided broken UIs caused by ghost configurations and created clarity in the deletion lifecycle until Site Studio provides native support.

5. Ensure All Packages Stay In Sync During Changes

Why it matters: Changing a shared component (e.g., a layout or a style) may affect multiple packages. Site Studio provides no built-in dependency tracking, so missing updates can cause functional drift.

What we implemented:

• Enforced a rule: “If you change a config item, you own its package update.”
  
• Used version control to detect config drifts across branches
• Required devs to re-export all impacted packages after config edits

Result: Fewer broken builds during CI/CD, reduced QA rework, and better auditability of configuration changes across the team.

Strategic Benefits

• Clean Separation of Concerns: No more stepping on other teams’ toes. Every package had a clear purpose. Templates didn’t interfere with styles. Components didn’t duplicate across brands.
• Faster Onboarding: New devs could clone a brand config set and start building immediately. No guesswork. No dependency hell.
• Environment Parity: QA stopped catching issues that “worked on local.” Our imports were consistent, version-controlled, and testable.
• Component Reusability: Teams could confidently reuse layout components across microsites, knowing exactly which config to pull in, and how.
• Governance-First DXP Delivery: The biggest win: we turned Site Studio into a governed, versionable system. Not a sandbox.

Lessons Worth Sharing

From our implementation journey, a few core lessons stood out, principles that transformed Site Studio from a rapid prototyping tool into a disciplined, enterprise-ready framework.

Configuration Needs To Be Governed Like Code

Site Studio empowers rapid UI development, but without structural discipline, it creates risk. Our packaging system brought DevOps rigor to a tool originally designed for speed.

Packages Are The Unit Of Scale

Don’t treat Site Studio packages as throwaway exports. Treat them as building blocks of your platform’s architecture. Version them. Scope them. Document them.

Delivery Confidence Comes From Config Predictability

The best component library in the world is useless if your layout breaks during deployment. Package governance isn’t just about structure; it’s about protecting delivery velocity.

Frameworks Turn Chaos Into Repeatability

Once we rolled out this framework, we were able to scale across microsites, teams, and QA environments without friction. That kind of repeatability is what makes Site Studio sustainable at enterprise scale.

The Missing Piece In Most Site Studio Projects

Most teams using Site Studio focus on design systems and layout strategies. Few talk about governance at the config level.

But that’s where enterprise complexity creeps in, and where failure usually starts.

This framework won’t just make your exports cleaner. It will make your entire Site Studio experience predictable, portable, and production-grade.

If you’re working on or struggling with a growing Site Studio setup, this playbook can help you stabilize before scale breaks your velocity.

Want to implement this for your team? Let’s share notes.

Let’s turn low-code into high-performance.