Development of a white-label solution on 1C-Bitrix

White-Label Solution Development on 1C-Bitrix

A white-label solution on Bitrix means a development company creates a product that its clients sell under their own brand. A tour aggregator, payment gateway, CRM system, marketplace — all of these can be built as white-label: one codebase, dozens of installations with different branding. Or a single installation with multi-tenancy.

The key technical question at the start: one shared codebase for all clients, or a separate instance for each?

Two Architectural Models

Bitrix multisite (one instance, multiple sites). Bitrix supports multiple sites within a single installation. Each site is a record in b_lang, a separate template in /local/templates/{SITE_ID}/, and its own settings in b_option. Data (products, users, orders) can be shared or separated by site.

Suitable when:

• There are few clients (up to 20–30 sites)
• Data is partially shared (single catalogue, different prices)
• One team administers all sites

Separate installations. Each client gets an independent Bitrix installation. The shared codebase is delivered as a module or via Git. Updates are rolled out separately to each instance.

Suitable when:

• Clients want independence (their own data, their own backups)
• Different configuration for each client
• Data isolation requirements (GDPR, healthcare)

Multi-Tenancy Within a Single Installation

For aggregators and SaaS products, a multi-tenant architecture is built on Bitrix:

• b_lang table — each site (tenant) with a unique LID
• Templates — a shared base template (/local/templates/base/) + overrides in /local/templates/{TENANT_ID}/
• Tenant settings — a custom table b_tenant_settings with TENANT_ID / KEY / VALUE pairs
• Users — shared b_user table, separated by groups and by SITE_ID

Branding each tenant:

// In init.php or in the template header
$tenantId   = SITE_ID; // LID of the current site
$tenantConf = TenantSettingsTable::getByTenantId($tenantId);

define('TENANT_PRIMARY_COLOR', $tenantConf['PRIMARY_COLOR'] ?? '#0052cc');
define('TENANT_LOGO_URL',      $tenantConf['LOGO_URL'] ?? '/logo.svg');
define('TENANT_DOMAIN',        $tenantConf['DOMAIN']);

CSS variables are generated dynamically via PHP and cached at the page level:

// Dynamic CSS with tenant colours
$css = ":root { --primary: " . TENANT_PRIMARY_COLOR . "; --brand-font: " . $tenantConf['FONT'] . "; }";

Developing the Product Core as a Bitrix Module

If the product code is delivered to multiple clients, it is best packaged as a Bitrix module. The module is installed via /bitrix/admin/partner_modules.php and registered in b_module:

/local/modules/vendor.whitelabel/
├── install/
│   ├── index.php          # module installer
│   └── db/install.sql     # creation of custom tables
├── lib/
│   ├── TenantManager.php
│   ├── BrandingService.php
│   └── ...
├── options.php            # module settings in admin panel
└── include.php            # autoloader connection

Advantage: the module is updated via the standard Bitrix mechanism (ModuleManager::isModuleInstalled(), ModuleManager::install()), analogously to standard modules.

Feature Gating by Pricing Plans

White-label often involves pricing plans: basic, standard, premium. Each plan enables or restricts a portion of the functionality.

Checking feature availability:

// TenantLicenseManager.php
public static function hasFeature(string $feature, string $tenantId = SITE_ID): bool {
    $plan = self::getTenantPlan($tenantId); // 'basic' | 'standard' | 'premium'
    $features = self::PLAN_FEATURES[$plan] ?? [];
    return in_array($feature, $features, true);
}

// In component or controller code
if (!TenantLicenseManager::hasFeature('advanced_analytics')) {
    // Show a stub or redirect to the upgrade page
}

The feature matrix is stored in code (a constant array) or in the database. Plan changes are applied without deployment — only an update to the record in b_tenant_settings.

Admin Interface for Clients

A white-label client must be able to manage their own instance. This is not the standard Bitrix admin panel — it is excessive and insecure for external users. A separate "partner dashboard" is built:

• Branding management (logo upload, colour selection)
• User management for their tenant
• Statistics and analytics viewing
• Notification and integration settings

Implementation — a dedicated site section with authentication by user group TENANT_ADMIN. Components in /local/components/vendor.whitelabel/tenant.admin.*.

Updating the Codebase

Supporting multiple installations is the most complex operational task. With separate instances, an automated update deployment system is needed:

• Git repository with the module/template code
• CI/CD (GitLab CI, GitHub Actions) rolling out to each server via SSH or Ansible
• Versioning: the module has a VERSION in install/index.php; before updating, compatibility with the Bitrix version on the client's server is checked

With a single installation, updates are simpler — one deployment.

Data Isolation Between Tenants

A critical security question: tenant A's data must not be visible to tenant B. All queries to info blocks must include a mandatory filter by SITE_ID or by a custom TENANT_ID field:

// Basic query with mandatory tenant filtering
$filter = array_merge($userFilter, ['=PROPERTY.TENANT_ID' => CURRENT_TENANT_ID]);
$res = CIBlockElement::GetList([], $filter, ...);

For sensitive data (payment information, personal data), database separation between tenants is recommended — each tenant works with its own PostgreSQL schema. Bitrix does not support this out of the box, but it is achievable by switching the $DB object at the start of each request.

Timelines

White-label on Bitrix is a non-standard use of the platform, requiring a deep understanding of its architecture. With the right design, the system scales from 5 to 500 clients without rewriting the core.