Installing 1C-Bitrix: where it breaks at the start
Turnkey 1C-Bitrix installation breaks not on the choice of edition, but on details that are visible only in operation.
File permissions are set for the FTP user rather than the web server account: cache and upload directories get read-only mode, and uploading an image to the infoblock ends with a 500 error for the content manager.
The site itself still opens — so the failure is noticed a week later, when content has already stalled.
The second typical failure is that the update agent is not running: the task in the scheduler has not been created, so mail events, search reindexing, exchange with 1C, and backup creation do not trigger.
Updates stop arriving, and there is nothing to restore from in a failure — there are simply no copies.
The third failure is almost invisible: the request form says “thank you,” but the email goes to spam or is rejected by the mail server due to missing domain records. Requests are lost in the very first weeks, and they are only learned about from a client who called on their own.
Most errors during site deployment appear after handover, and they share one thing: at the start, no one checked what exactly works and what is silent. Below we break down how this is closed at the installation and initial setup stage.
What correct installation gives: speed and fewer failures
A correct 1C-Bitrix installation is not unpacking the distribution onto the production server, but a predictable environment configuration: permission separation, a separate test environment, cache setup, a task scheduler, and a backup policy.
Two metrics that the customer notices before others directly depend on it: time to site launch and recovery time after a failure.
The time to the first working site is reduced when installation follows a proven template: standard environment settings are applied in one pass rather than assembled manually for a specific case.
The first public release comes out several times faster, and editors begin filling sections in parallel with refinements, without waiting for final acceptance.
A separate effect is an eliminated class of failures. Permission errors, incorrect paths to directories, forgotten temporary directories, and missing limits on uploaded files cause publication failures at the worst possible moment.
Built-in restrictions and input checks remove this class entirely rather than dealing with it incident by incident.
Recovery time is measured not by the presence of copies, but by whether their deployment was tested. A backup of the database and files together with a documented recovery procedure returns the site to a working version in minutes instead of hours of searching for the cause.
Publication stability rests on a predictable environment: changes pass through the staging environment, deployment is automated, and rollback to the previous version is performed in one operation. The editor then does not depend on who changed the server settings and when.
How we deploy: cloud, server, virtual machine
Hosting sets the project boundaries more than it seems: it determines which platform modules are available, how caching is configured, whether the database can be moved to a separate node, and how often the environment is updated.
Therefore, the choice begins not with capacity, but with the limitations the customer is willing to accept.
Hosting options and their boundaries
| Option | When it fits | Limitations |
|---|---|---|
| Cloud plan | Typical project, medium traffic, predictable launch needed | Some server-level settings are closed, environment updates follow the provider's schedule, system logs are not fully available |
| Virtual machine | Need custom web server rules, additional extensions, separate roles for application and database | Resources are shared with neighbors on the node — peaks may cause drops; some operations require approval |
| Dedicated server | High load, heavy catalog, intensive exchange with the accounting system | Administration, backup, and fault tolerance are assembled separately and on the customer's side |
| Local environment without external access | Data must remain within the perimeter, work is only on the internal network | No external updates or cloud services — updates, licenses, and mail are delivered manually |
Before deployment, we check the exchange requirements with the accounting system, the backup scheme, and the update procedure against the chosen option — at this stage it is clear where the configuration will hit the platform's limitations. If there is a discrepancy, it is cheaper to resolve before data migration than after launch.
Implementation stages: from audit to access handover
The order of steps is fixed not for beauty: installing 1C-Bitrix on an unchecked environment almost always ends in rework.
If the interpreter or its extensions do not match the core requirements, some modules fail already at the unpacking stage, and discrepancies in permissions and limits surface later — on production traffic.
Therefore, we first inspect the platform, then agree on the hosting scheme, and only after that change the configuration.
- Environment audit: interpreter version and set of extensions, memory and execution time limits, directory permissions, scheduled tasks, DBMS availability. The output is a report with discrepancies and a list of corrections to be made before installation.
- Hosting scheme: we determine where the web part, database, and user files live, what is moved outside the document root, how backups and log rotation are organized. The scheme is agreed before work — moving it later is more expensive than designing it right away.
- Initial setup: current branch kernel, encoding, permissions, mail queues, caching, human-readable URLs, license, exchange with the accounting system.
- Acceptance checks: a checklist for authorization, group permissions, page responsiveness, mail sending, and data exchange. A separate item is taking a backup and deploying it on a clean environment.
- Access handover: accounts with roles, maintenance policy, documentation on configuration and points that cannot be changed without approval.
What you keep: configuration, access, policies
We hand over not only a working site, but also a set of artifacts by which the system can be maintained without the authors.
A month after launch, the administrator raises the staging environment according to the description, not from memory, and understands in advance which changes are safe and which break integrations.
- Configuration documentation — module composition, kernel branch, which components and templates are overridden relative to the standard distribution, which settings were changed and why.
- Hosting scheme — what lives where (web layer, database, cache, search), which ports are open to the outside, where failure points are, and what degrades first under load.
- Access policies — roles in the admin area, permissions for directories and files, separate accounts for content, development, and contractors, and a ban on edits directly on production.
- Backup policy — what is backed up (files, database, configurations), how often, how long it is stored, where it is exported, and how recovery is tested.
- Update policy — procedure for installing 1C-Bitrix and module updates: first a copy of the environment, then production, with a work window and a described rollback.
- Administrator guide — typical operations: connect a new domain, adjust mail notifications, investigate an incident, what to look at in logs on error.
- Access handover — via a secure channel, indicating the owner of the credentials and the procedure for changing them when an employee leaves.
Each item is agreed with your team: if you manage something differently, we record your procedure rather than impose ours.
Project: migration and launch of a corporate portal
The customer is a manufacturing company; the corporate portal served several hundred employees: policies, requests, department news, data exchange with the accounting system.
The portal lived on an outdated environment, publishing materials took about two hours, and failed publications brought down the section until the on-call engineer intervened manually. The migration had to fit into a weekend without stopping work on Monday.
We deployed the target platform on 1C-Bitrix in the current branch, raised a database replica, migrated the file storage, and warmed the cache with search reindexing before switching traffic.
The switch was staged, with checksums of attachments verified; the old platform was kept in hot standby for another week — rollback would have taken minutes, not hours.
Metrics before and after migration, according to monitoring data for the first month of operation:
| Metric | Before | After |
|---|---|---|
| Full portal launch | ~2 h | ~15 min |
| Publication failures | 6–8 per month | 0–1 per month |
| Recovery after failure | 40–60 min manually | 5 min per policy |
| Downtime during migration | — | 0 during working hours |
What remained was the policy: we install updates on a copy, publications undergo preliminary checks, and the on-call engineer sees an incident before users do. Publication stability stopped depending on manual actions and became a measurable parameter.
What to do if the site already runs on an old environment
A working site has three paths: migrate the entire environment, migrate section by section, or refine it in place.
The choice is determined by two factors — how many minutes the site can be unavailable and how much the sections are connected by common logic, catalog, and authorization.
We build zero-downtime migration through a parallel environment: we raise a copy of the environment alongside, enable database replication and synchronization of uploaded files, and reduce the DNS record TTL in advance.
In essence, this is installing 1C-Bitrix anew — on a clean environment, with data migration. The switch takes minutes, and the former environment remains a hot standby: rollback does not require restoring from an archive.
The phased option helps with an almost zero maintenance window: we migrate sections one by one, distribute traffic via routes, and keep the session and permissions shared.
Refining an existing site without migration gives a targeted effect — we update the kernel to the current branch, enable page caching, and configure exchange with the accounting system at the level of catalog sections.
We make the decision after inspection: we look at the section map, database connections, catalog weight, and frequency of current failures. Then — a test environment, a run on a copy of traffic, and a rollback plan. Describe what hurts on your site — we will come back with a migration scheme and estimate.
Technical concerns: licenses, migration, updates
Concerns at this stage rarely relate to whether we will do the work — more often they ask about operation: what will happen to the license during migration, whether environments will match, what access will be needed, and who is responsible for updates after handover. We answer briefly and to the point.
Each of these objections is closed by a procedure, not a promise. We process the license transfer before switching the domain, check environment compatibility on a copy of 1C-Bitrix, issue access narrowly and revoke it, and record the update policy in the documentation.
Is the license transferred when changing server or hosting?
Yes, it is transferred: binding is to the product and domain, not to hardware. We reissue and activate on the new environment in advance while the site runs on the old one — downtime during switching is measured in minutes.
What if the environment versions on the server and locally differ?
We compare language, database, extension set, and encoding versions at the reconnaissance stage. We close discrepancies on a copy: install additional modules, adjust settings, and run key scenarios. Only a verified configuration goes to production.
What access is needed and what happens to it after handover?
We need access to the hosting panel or server, to the database, and to the site's admin area. We issue only what is necessary for the task, restrict by addresses, and revoke upon completion. Your administrators' accounts remain.
Who is responsible for updates after handover?
We update on a copy, check scenarios, and only then transfer to production — with a backup before every change. We work on a schedule plus unscheduled security releases; rollback is restoring a copy in one step.
Let's discuss the task: what we clarify before starting work
Before the estimate, we need to remove uncertainty: the same task of “installing Bitrix” turns into different projects depending on load, number of environments, and integrations.
Therefore, before the start we break down the task point by point and record the answers in writing — they become the basis of the work plan and acceptance criteria.
- Load profile: peak traffic and its seasonality, share of authorized users, catalog size and update frequency, expected number of concurrent sessions.
- Environment scheme: how many environments are needed — production, test, local for development — and how data and configuration are transferred between them.
- Integrations: exchange with 1C for goods, stock, and orders, payment gateways, delivery services, CRM, and external services — what gives data, what receives it, and at what frequency.
- Data and migration: whether we migrate existing content and catalog, what we do with old page addresses, and how we set up redirects so as not to lose search positions.
- Fault tolerance requirements: backup, recovery procedure, allowable downtime during updates.
- Access and roles: who on the customer side provides access to the server, domain, 1C, and advertising accounts, and who accepts the result.
- Timelines and responsible parties: launch date, events tied to it, approval points, and reporting format during work.
After this conversation, we have enough inputs to come back with an estimate, work plan, and environment scheme — without assumptions that later turn into rework.