SystemFlare
ES Talk to an engineer

E-commerce · Electronics retail

From FTP edits to an AI-managed pipeline in about a week

Two online stores, 42,000 products synced from 1C, and changes made directly on the live server. One week later, the owner was shipping changes by describing them to an AI agent.

~1 week
from first look to a working gated pipeline
42,000
products synced from 1C, untouched by the move
6 h
database backup interval, restore tested
Next day
first owner-requested changes live

The situation

A regional electronics and laptop retailer runs two online stores on OpenCart and ocStore, with about 42,000 products. Products, prices and stock arrive from the company’s 1C accounting system.

Over the years the stores had been changed the way many shops are: directly on the server.

  • There was no Git. Several FTP users had write access to production.
  • phpMyAdmin was open to the internet.
  • The webroot held database dumps, archives and stray scripts. One of them ran ALTER TABLE when opened in a browser, and another sent an email.
  • PHP could execute anywhere, and the 1C exchange endpoint accepted requests from anyone.

Nothing had gone badly wrong yet. But any change was risky, and nobody could say exactly what was on the server.

What we did

Safety first.

  • Encrypted off-site backups: the database every 6 hours and the files nightly, with a restore verified by checksum.
  • The server was hardened:
    • ports 80/443 accept traffic only from the CDN;
    • PHP runs only for the store’s own entry points;
    • the 1C endpoint accepts only the 1C server’s IP;
    • SSH is key-only, and FTP was removed.
  • Removed files went to quarantine, not to the bin.

Code into Git.

  • After a scan for leaked secrets, both stores went into a private GitHub organisation that the client owns.
  • A separate staging server got a sanitised copy of the database. On staging, payments, analytics, pixels, affiliates and social login are switched off and the domains are rewritten.

The pipeline.

  • Every pull request is checked for PHP syntax (for the server’s PHP version), leaked secrets and forbidden files.
  • Risky changes are flagged for an engineer: configuration, CI, dependencies, SQL, the 1C exchange, OCMOD modules and code that deletes data.
  • A production deploy runs a gate on the server itself. It takes a database copy, deploys the code, rebuilds modifications and checks that the site responds, then rolls back on its own if it does not.
  • A nightly drift check compares production with Git and opens a ticket if anything changed outside the pipeline. Deploys stay blocked until that is resolved.

Handover to the owner. The owner installed the Claude and GitHub apps, which took about ten minutes. Now they request changes in plain language, check them on staging and approve. The first customer-facing fixes, a language redirect and product markup, went live the next day.

Extras on top

Once the store could be changed safely, adding automation was easy:

  • an AI-drafted blog article every morning, which the manager reviews;
  • automated Telegram posts: daily prices, “price dropped” alerts and a weekly selection for the store’s channel.