Releases 20261101.1–20261103.1 and separate plans

Release 0.1.0-beta.20261023.1 already fixes team lead access to campaigns shared with their staff and video thumbnail preparation in Autolaunch. See Team lead and their media buyers and Autolaunch. Version 0.1.0-beta.20261101.1 includes the page protection and permission fixes below. Version 0.1.0-beta.20261101.3 adds BigoAds spend, per-status postbacks in source templates, new report filters and compact list actions. Version 0.1.0-beta.20261102.1 makes reports with BigoAds spend fast again, speeds up other reports, keeps a paid tracker working without the license server for up to 24 hours and adds spend extension 1.2.4, a 24-hour preview of protected pages and compact file editor buttons. Version 0.1.0-beta.20261103.1 fixes team lead access, counts clicks in the offer list as offer visits, adds visit metrics to reports, brings the report period window to the campaign, landing page and offer lists, adds totals for selected rows and no longer counts a click-through when the browser loads an offer link as a page resource. Automatic cleanup, the new visible time zone selector and site payment fixes are still being prepared separately.

Other changes in the combined bundle

The release combines groups and permissions, faster lists and campaign actions, instant stream selection, complete Keitaro transfer, source and network permissions, conversion-type editing, report precision and automatic PHP recovery. A database deadlock between node failover and a concurrent manual domain route is fixed. Updating does not start an import or activate direct-link protection. FTP/FTPS remains deferred.

Automatic rollback cleanup

Automatic cleanup of local update copies is prepared with a default retention of 7 days. The installation owner can change the period or disable automatic cleanup. Checks run once an hour.

• Pinned copies are retained regardless of age.
• Failed, unfinished and unknown operations are not removed automatically.
• Existing copies receive a full retention period when cleanup is first enabled.
• With automatic cleanup enabled, expiry also applies to the last unpinned copy. Pin it first if it must remain longer.
• With automatic cleanup disabled, the previous manual cleanup continues to retain the two latest copies.

These are local rollback copies on the same server. They do not replace backups on separate storage.

Keitaro working archive

After a fully successful migration, the working archive copy can be removed after 1 day. Configuration success alone is insufficient: pages, the migration result and all history must be verified, and background loading must have finished.

The original archive and source Keitaro remain. Failed, stopped, unknown or running migrations retain their working files. Older successful migrations receive a full retention period when cleanup is first enabled. See Keitaro migration for the migration process.

Visible time zone selector

In Reports («Отчёты»), the Time zone («Часовой пояс») field will sit next to the period. The builder and Click log («Клик-лог») use one selected zone, including click-log row times. Changing the zone recalculates the report; drafts and saved reports preserve the choice.

Select a zone such as Europe/Moscow or America/New_York. Day boundaries and calendar grouping use that zone. Named zones account for daylight-saving changes where applicable. The source event timestamp does not change.

The published version already offers a zone inside the period picker — see Period, time zone and attribution. The prepared change exposes the selector and aligns the click log with the report.

Pages, forms and source access

The version includes limited visits, separate source/ZIP permissions, a complete page version for open forms, publication review and diagnostics without form data. The built-in form-data file log is disabled; custom PHP handlers remain.

See Hosted page protection for usage and limits. Updating does not enable protection automatically: a separate transition requires installation checks.

HTML size and form responses

A 16 MiB (16,777,216 bytes) limit applies to source HTML and the complete HTML after macro substitution and link rewriting. Compressed PHP HTML responses are also checked after decompression. Protected delivery applies the same limit to transformed CSS, JavaScript and .mjs files, before and after rewriting. Ordinary videos, images and other resources that are not transformed retain their existing limits and streamed delivery.

An oversized .html or .htm file uploaded directly or in a ZIP is rejected with HTTP 413 (html_too_large); the previous page version remains. If the limit is exceeded while serving a page, the visitor receives HTTP 500 without a partial transformed response or a truncated form. For local CSS/JS with valid original SRI, the hash is recalculated from the bytes delivered to the browser. The tracker does not repeat the PHP POST: the handler may already have performed its action, so a response error does not mean it is safe to submit the form again.

The limit also affects previously hosted pages. Before updating and activating protection, check large HTML files, macro output and CSS/JS that protected delivery will transform. Large embedded resources can be moved into separate files. See hosted page limits and PHP limits. These changes are included in this version; check the actual installation and your pages before activation.

PHP sessions and temporary files

PHP session isolation works with page protection and recovery. New php-private and php-net-private pools use separate temporary directories for each page. Publishing another version of the same page does not by itself change its session directory. A copied page or another PHP pool has separate state; the PHPSESSID cookie neither transfers a session nor identifies the owner of old files.

During an ordinary update, cold backup or permitted rollback, the installation service preserves the running php and php-net containers and their /tmp: they are neither stopped nor recreated. New private pools start alongside them. If an operation would replace an already pinned PHP runtime, it stops for review while leaving the pools running. This does not promise an update of the whole tracker without a pause.

At the first transition, the installation service stops the previous unverified backup operator and pins a durable ingress barrier before changing any restart policy. It then verifies preservation of the old PHP pools and starts the approved backup operator before publishing PHP pins. An interruption can leave the barrier closed; a running container or PHP readiness does not prove traffic is open. Investigate the cause and retry the original operation through the normal procedure. Do not delete the service barrier manually. Backups may also remain unavailable until continuation succeeds.

Before activation, compat applies. For 48 hours after the transition starts, old direct paths and POSTs without a protected visit retain their public contract, including a form returning to the campaign link. This is a bounded compatibility window, not proof that a request came from an already open tab: the old pool's shared /tmp remains shared during it. New GET visits after the transition starts and requests with protected access use private pools. A header, query parameter or PHPSESSID cannot select the old pool for a protected request.

The controller retains the binding to running PHP containers and checks readiness before activation. The new Go application uses a root-owned service marker check before PHP execution: if the marker is missing or forged, the next request receives 503 before the form handler, without repeating the POST. This prevents a silently empty session; it does not restore lost state.

Lost session contents are not restored. After a verified server restart, the new contract automatically creates a new PHP generation; other cases require manual review. For manual recovery, the owner explicitly accepts losing all sessions using sudo micatorctl php-recover with five required flags. First pinning changes legacy runtime restart policy to no without stopping the pools. After recovery, legacy stays retired and old forms and grants are closed. A fresh campaign GET receives a protected visit even before arm, an old raw POST is not retried, and plan dates remain unchanged. See PHP recovery for the exact command and boundaries.

Each installation needs checks beyond release archive acceptance: both PHP modes, old and new form links, HTTPS, every origin/LB/node and caching. See page protection for activation, the immutable root plan and rollback limits; see the recovery guide for lost state and final recovery checks.

Recovery after state loss

The new contract requires controller 20261101, php_transition format2 and hosted:access_rollout_v4. Losing one pool rotates the global PHP epoch: this is a session and grant generation, not a page file revision. A verified server restart can start automatic recovery under the new contract; the explicit root command remains available. While recovery keeps the applications stopped (with an old application, until the compatible release is installed), traffic gets a 503 maintenance answer. An interrupted intent resumes its original generation. After a permitted old Go rollback, an approved signed --target-version may be needed. Check state with sudo micatorctl php-status. PHP generation readiness is not update completion: the same confirmed command continues the original recovery job without another session rotation. Previously accepted, pinned exact candidate bytes permit retry despite latest-catalogue changes or expiry of the original catalogue: procedure and boundaries.

Counter, notification and draft permissions

The shared offer click counter is limited to owners and admins. An offer may receive traffic from campaigns belonging to different teams, so owning or sharing the offer does not grant access to its overall total. Other roles will see The shared counter is available to the installation owner and administrator. Existing permissions to configure the cap remain; reports still show statistics for accessible campaigns.

The Offer cap reached notification, for both clicks and sales, is also limited to owners and admins. Previously stored notifications of this kind are hidden from other roles, including the unread count. Other notification kinds retain their existing rules.

The draft catalogue is fixed for media buyers and team leads granted Manage access to a campaign group: an accessible draft appears in both the general catalogue and the selected campaign list. Read-only group access does not grant this permission. User restrictions, draft authorship, access revocation and team changes still apply.

With No access to Reports, hourly, daily and total stream cap counters are also unavailable. The API refuses access, and the stream window shows Counters are unavailable due to access restrictions («Счётчики недоступны из-за ограничений доступа»). Users can still configure caps if they have permission to edit the campaign.

New notifications about an offer or landing page going down or recovering, and about domain replacement in a stream, account for direct campaign sharing, campaign group sharing and a team lead's access through their media buyers. The current team, user restrictions and notification preferences apply. This fix does not rewrite the history of those notifications.

Checking backups before cleanup

Before deleting old remote backups under the Last N rule, cleanup checks the presence and size of the files of every backup from this installation involved in the calculation, including the newly retained backup. Cleanup stops if files are missing, have an unexpected size or cannot be read. Check or restore the copies and try again. File size checks during cleanup do not replace checksum verification or verification for restore.

Changing a key during an Autolaunch check

Changing or disconnecting the key during a background rules check stops the old cycle from sending data to the new profile; the next check uses the current key. This does not cancel requests already sent to Meta or undo advertising actions already performed. See Meta Autolaunch for setup.

Invoices and promo codes in the website account

Two billing fixes are prepared for the next website update. A saved invoice or checkout link will open the exact order even when it no longer appears among the latest 200 orders in history. Access remains limited to the order's owner.

If Heleket cannot create an invoice for a long time and the promo reservation expires, the server will recheck the code before retrying. An already open invoice with a valid reservation keeps its agreed discount when the promo code is changed later. If a late transfer arrives after its reservation was released and taken by another order, the payment details are kept for support; do not send another transfer. In this case, the license is not issued automatically.

BigoAds spend

Release 0.1.0-beta.20261101.3 adds BigoAds spend collection beside Meta Ads: a separate ad ID field and traffic sources, extension 1.2.1 with a mode for all accounts of an organization, and a shared reconciliation. Setup is in BigoAds spend, the API in Admin API: spend.

Per-status postbacks in source templates

In the same release, a catalog template can set a separate postback URL for each status. The “adsbigo.com (web)” template is updated to version 2: the click ID in external_id, the account ID in creative_id, and registration and purchase postbacks. The source card gets an Insert postbacks from template («Вставить постбеки из шаблона») button; a source created from an older template version shows that the template was updated. Details: Rows from the template and adsbigo.com (web), version 2.

Report filters and list actions

In release 0.1.0-beta.20261101.3, report filters are condition cards like in the stream editor. The field is chosen from a searchable list, as are the values of the Campaign, Campaign group, Offer, Landing page, Source and Country fields; the Parameter («Параметр») list of stream filters has a search too. Saved reports and links work as before. How to search: Search in the list.

Row actions of offers, landing pages, domains, networks and the trash share one compact style: buttons do not wrap and do not cover table data. For landing pages, the table row and the phone card have the same buttons in the same order: Preview ↗ («Предпросмотр ↗»), Copy («Копировать»), Editor («Редактор»), Diagnostics («Диагностика»), Access («Доступ»), ✕; the phone Code («Код») button is now called Editor. Who sees which buttons: Landing pages table.

Release 0.1.0-beta.20261102.1

An urgent update after 0.1.0-beta.20261101.3, with no new migrations.

• Reports with imported BigoAds spend are fast again. Other reports are faster too: when every report row fits on one page, totals are summed from those rows without a separate query. Spend, revenue and profit are calculated as before.
• Spend extension 1.2.4: auto-collect every 3 minutes for Meta Ads and BigoAds, a compact window, a BigoAds day without spend sent as zero and clearer collection messages. After the tracker update, download the extension again with Download extension («Скачать расширение») on the Settings → Costs tab — see Spend extension.
• The 24-hour preview of a protected page closes at once when the staff member loses access to the page.
• Compact file editor buttons: less frequent actions are in the More («Ещё») menu.
• Paid license: when the license server is unreachable, the tracker keeps working fully (panel, postbacks and CAPI, spend collection) for up to 24 hours after the last successful check and never beyond the license term. This needs the updated micator.com license server; the trial license works as before. Details: License service unavailable.

24-hour preview of a protected page

Included in release 0.1.0-beta.20261102.1. It applies to installations with page protection enabled; until protection is enabled, Preview ↗ («Предпросмотр ↗») opens the previous direct address.

• A preview lasts up to 24 hours, like an ordinary visit, instead of 5 minutes. A long check of a form and the pages after it is not interrupted.
• Access stays bound to the browser (cookie), the traffic domain and the page: a copied link does not open in another browser.
• A preview closes at once when the staff member loses access to the page: when their settings are saved in the Permissions («Права») window of the Team («Команда») section (for example Preview («Предпросмотр») → Denied («Запрещено»), a denied section, or access to all offers or landing pages removed), when their role or login changes, when the staff member is deleted, and when the Access («Доступ») granted to them for an offer or landing page is removed. To open the page again while the right remains, click Preview ↗ once more.
• Visitor visits and other staff members' previews stay open. To close all access to a page at once, use Revoke visits («Отозвать посещения»).
• If the service storage is unavailable, the permission change is not saved and the panel shows "Open previews could not be closed. Permissions are unchanged — try again later." Save again later.
• The page's own cookies, such as its session after a test application, are kept as for an ordinary visitor: the preview does not reset them.

Compact file editor buttons

Included in release 0.1.0-beta.20261102.1. It applies to the file editor of landing pages and offers; button names do not change.

• ← Back to landing pages («← К лендингам») / ← Back to offers («← К офферам»), Open ↗ («Открыть ↗»), + File («+ Файл»), Versions («Версии») and Upload .zip («Загрузить .zip») stay above the editor. The buttons are more compact.
• File access («Доступ к файлам»), Diagnostics («Диагностика») and Export ZIP («Экспорт ZIP») are in the More («Ещё») menu. The menu also works from the keyboard: Enter, Space or the down arrow opens it, the arrows choose an item, and Esc closes it.
• On a phone, all these actions, including the way back to the list, are shown in a row above the files.
• For the open file, Rename («Переименовать») sits right after its path, and Save ⌘S («Сохранить ⌘S») is on the right. On screens narrower than 1024 pixels, Rename is shown as a pencil icon.

Spend extension 1.2.4: auto-collect every 3 minutes

Included in release 0.1.0-beta.20261102.1. It concerns the Meta Ads and BigoAds spend extension: after the tracker update, download it again with Download extension («Скачать расширение»). Details are in Auto-collect.

• The checkbox Auto-collect every 3 minutes: today and yesterday; the full period every 30 minutes («Автосбор каждые 3 минуты: сегодня и вчера; весь период — раз в 30 минут») replaces Auto-collect every 30 minutes («Автосбор каждые 30 минут»).
• Every 3 minutes the extension collects today and yesterday by the ad account's day, so fresh spend reaches the tracker every 3 minutes.
• The full Days back («Дней назад») period is collected at most once every 30 minutes, and also on the first auto-collect after the browser starts or the extension updates, after the account's day or time zone changes, and after settings are saved. With a period of 1–2 days, every run collects the full period.
• Collect now («Собрать сейчас») still collects the full period. Continue collection («Продолжить сбор») for an unfinished BigoAds queue of today and yesterday also starts the full period.
• A new run doesn't start while the previous one is running. A BigoAds queue over all accounts continues on its own; the next auto-collect starts after it completes.
• If the full period fails, the error stays next to the result of the today-and-yesterday auto-collect: “… · full period: …” («… · весь период: …») with the error text, and in the BigoAds collection («Сбор BigoAds») block “Full period: …” («Весь период: …»). It disappears after the full period is collected successfully.
• For Meta Ads: if the tracker rejects the key or the license, or Meta rejects the token or permissions or limits the request rate, auto-collect waits 30 minutes instead of retrying every 3 minutes. Collect now, Save («Сохранить»), a new sign-in to Ads Manager or another account end the pause. Network errors and temporary failures are retried in 3 minutes.
• Auto-collect skips a BigoAds account with a permanent error for today or yesterday, for example when the tracker didn't accept the spend, for 30 minutes. The other accounts of the organization are collected as usual, and the account's error stays in the list.
• After a two-day auto-collect, the extension window shows “Rows accepted: … · days: 2 (today and yesterday)” («Принято строк: … · дней: 2 (сегодня и вчера)»), and the BigoAds collection block shows “· today and yesterday” («· сегодня и вчера») in the collection mode line.
• If a Meta Ads auto-collect of today and yesterday doesn't fit into two minutes, the extension shows “Collection of today and yesterday took more than two minutes; we will retry on the next run” («Сбор за сегодня и вчера занял больше двух минут; повторим при следующем запуске»).
• A repeated snapshot of the same day replaces the amounts rather than adding to them.
• The tracker distributes a day's changed spend across campaigns at once, and a snapshot with the same amounts no more than once every 25 minutes, see Reloading a day. The Updated («Обновлено») column of the days table shows the time of the last distribution, not of the last collection.
• Starting with version 1.2.2, the extension window is compact and keeps its width: Collect now and the result line sit right below the status lines, and the hint “Open Ads Manager” («Откройте Ads Manager») or “Open ads.bigo.sg with the selected account” («Откройте ads.bigo.sg с выбранным аккаунтом») follows the platform selected in the Advertising platform («Рекламная платформа») list even before saving.
• Starting with version 1.2.3, a BigoAds day for which the dashboard shows no spend — no total and no ad with spend — is sent as zero and doesn't stop the collection. If ads have spend but there is no total, the day is not sent: “Bigo: the dashboard did not return the spend total for …; collect again later” («Bigo: кабинет не вернул итог расхода за …; повторите сбор позже»). An amount error names the dashboard response field, the value and the day: “Bigo: invalid amount in … (…) for …” («Bigo: некорректная сумма в … (…) за …») — see BigoAds collection errors.

Release 0.1.0-beta.20261103.1

An urgent update after 0.1.0-beta.20261102.1, with no new migrations.

• Reports and statistics load again for a team lead and other users with restricted access who see hundreds of campaigns: before, the dashboard, list metrics, reports, comparison, CSV export and the click log ended with an error for them. The number of visible campaigns no longer matters for the request.
• An owner or admin can grant campaign group access to a team lead as well — View («Просмотр») or Manage («Управление») in Campaigns → management → Access, as to a buyer. The grant is personal: the team lead's buyers do not receive it. Changing a user's role removes their group grants; the grant of a buyer promoted to team lead earlier applies after the update — check the groups' Access. Details — Campaign groups and Team lead and their media buyers.
• In the Offers («Офферы») list, the Clicks («Клики») column counts offer visits: stream clicks straight to the offer and transitions to the offer from a landing page. A landing page visit with an offer chosen in advance and no transition is no longer counted as an offer click — it is shown in the new Landing page visits («Входы на лендинг») column. CR in the list is calculated from offer visits. Details — Clicks and landing page visits.
• Reports have new metrics: Offer visits («Заходы на оффер»), Landing page visits («Входы на лендинг») and Offer CR («CR оффера»). The Clicks metric and the groupings have not changed — see Report metrics and formulas.
• The offer click cap counter counts as before: with an offer chosen in advance the slot is taken on the landing page visit, so the counter can be higher than the Clicks column.
• In campaign statistics, the Offers («Офферы») grouping also counts the Clicks and CR columns by offer visits.
• The Campaigns, Landing pages and Offers lists replace the Today / 7d / 30d («Сегодня / 7д / 30д») switch with the period window of reports: the presets, Date range («Интервал дат»), Time range («Интервал времени») and Time zone («Часовой пояс»). The default is Last 7 days («Последние 7 дней») in the time zone from your profile, and the choice is kept in the page address. The campaign list updates its metrics every 10 seconds only for a period of at most one day that runs up to now, and once a minute for other periods. Details — Metrics period.
• In reports, rows can be ticked, and the totals row becomes Selected rows total (N) («Итого по выбранным (N)»). The campaign, landing page and offer lists show Total («Итого») for the open page and Selected rows total (N) under the table. Counts and money are added up, while CR, ROI and other rates are recalculated from the sums — see Selected rows total and Page total and selected total.
• If an administrator hid a report metric, the campaign, landing page and offer lists show “—” in its column, and the other metrics load; the Report («Отчёт») tab of campaign statistics does not request such metrics — see User permissions.
• An offer link that the browser loads on its own — from <link>, <img>, <script>, CSS url() or in advance (prefetch, prerender) — is not counted as a click-through: no LP click is recorded, no slot in the offer click cap is taken and the offer does not open. A landing page with such a link will show fewer LP clicks: the earlier number was inflated. The review before publication warns about such a link — see Where to put the click-through link.
• After the update, a review before publication that was open and an approved Keitaro page review must be confirmed again: the review now includes the offer-link-autoload rule.

Before using these features

Compare releases 0.1.0-beta.20261101.1, 0.1.0-beta.20261101.3, 0.1.0-beta.20261102.1 and 0.1.0-beta.20261103.1 on Updates with your installed version. Publishing the release does not update your server automatically. After the tracker update, download spend extension 1.2.4 again and load it into the browser in place of the previous one. Protection requires separate activation; manual recovery requires explicit acceptance of session loss; a verified server restart can start recovery automatically under the new contract. Cleanup, the visible time zone selector and site billing await separate releases. Uninterrupted tracker updates are not announced.