27
Home/Platform
Architecture & deployment

Boring technology, deliberately.

A showroom cannot stop billing because a queue worker died or a cloud region had an incident. ambar 27 is built on a small, well-understood stack that runs on hardware you can point at — and keeps running when your internet does not.

PHP 8On FrankenPHP workers, no cold starts
MySQLOne relational database, one source of truth
161Versioned migrations, forward-only
On-premOr your own cloud account. Never ours.

The stack, in full

There is no microservice mesh, no message broker to babysit and no JavaScript framework between the counter and the database. A request comes in, a worker handles it against MySQL, and a page comes back. That is the whole architecture, and it is why it is fast and why it stays up.

  • Application: PHP 8 on FrankenPHP, run in worker mode so the framework boots once, not per request
  • Web server: Caddy, with automatic HTTPS certificate management
  • Database: MySQL, with performance indexes shipped as migrations
  • Storage: local filesystem or any S3-compatible bucket, via Flysystem
  • Realtime: Pusher channels for counter and cashier updates
  • Native helpers: Go binaries for PDF generation and face recognition
Request pathSimple by design
1
CaddyTLS termination, static assets, routing
2
FrankenPHP workerFramework already booted, request handled in-process
3
Router → middleware → controllerAuth, role check, channel scope
4
MySQLIndexed reads, transactional writes
5
Rendered pageServer-rendered HTML, no client hydration
No queue, no broker, no build step4 moving parts

Deployment: your hardware or your cloud

ambar 27 is installed for you, on infrastructure you own or rent in your own name. There is no shared multi-tenant database, no vendor lock on your data, and no scenario where a billing dispute takes your store offline.

  • On-premise: a server in the showroom, so billing survives an internet outage
  • Your cloud: your AWS, DigitalOcean or provider account, in your region
  • Hybrid: an on-premise node per branch with consolidated reporting
  • Automated deploys through a CI pipeline, with versioned releases
  • Database backups on your schedule, to storage you control
  • You get the credentials. Access is granted to us, not assumed by us.
Deployment optionsChoose one
On-premise serverOffline-tolerant
Your cloud accountYou own the bill
Hybrid per branchConsolidated MIS
Managed by usOn your infrastructure
Multi-tenant shared databaseNever

Performance under a festival rush

The load pattern in Indian textile retail is brutal and predictable: eleven quiet months, then a Diwali week where every counter bills continuously. Worker mode and indexed reads are what keep an invoice under a second when all of them are busy.

  • Worker mode eliminates per-request framework boot
  • Performance indexes shipped as explicit, reviewed migrations
  • Application-level caching for settings, features and permissions
  • Paginated registers — no report loads an unbounded result set
  • Worker count tuned to the box during implementation
  • Thermal and direct printing bypass the browser print dialog
Tuning knobsSet at install
Worker countMySQL buffer poolIndex strategyCache TTL Pagination sizeReport period capsS3 vs local storageBackup window Realtime channelsPrint queue
Sized against your peak day, not your averageTuned
Integrations

What it connects to.

Every integration uses your own credentials and your own accounts. We do not resell you an API.

GSP / e-invoice

IRN generation and cancellation with signed QR, plus e-way bill generate and cancel, configured per GSTIN with your GSP credentials.

GSTN returns

GSTR-2A purchase register download and GSTR-2B reconciliation data pulled for matching against your purchase register.

Tally

Ledger mapping for sales, purchase, GST and expense heads, with XML voucher, ledger, stock item and unit generation.

WhatsApp Business

Your business account and phone number ID, sending templated document messages for invoices, receipts and statements.

Razorpay

Online collection with reconciliation back to the customer ledger and the card settlement flow.

Bank statements

Statement import and matching against recorded bank transactions to drive reconciliation inside the ledger.

QZ Tray & scanners

Direct thermal and label printing with a digital certificate, plus a dedicated scanner app for stock taking and inward.

Face recognition

A native Go service that registers employee face descriptors and matches attendance, running entirely on your server.

Pusher

Real-time channels so counters, cashiers and floor managers see the same figures without refreshing.

A documented REST API

Scanner tablets, feedback devices and your own tooling talk to ambar 27 over an authenticated REST API. If you need to push data from a marketplace, a website or a legacy system, that is the door — not a database connection.

Implementation

How a rollout actually goes.

The software is already written. What takes time is your data, your rules and your people — so that is where the schedule goes.

Typical timelineSingle showroom
Discovery & scopingWeek 1
Masters & migrationWeeks 2–4
Parallel runWeeks 4–6
Cutover & trainingWeek 6–7
Hypercare supportWeeks 7–11
Multi-branch rollouts run branch by branch~7 weeks

Discovery and scoping

We walk your floors and your books: counters, warehouses, GSTIN structure, cheque practice, jobwork flow, incentive schemes, and who is allowed to approve what. The output is a configuration document you sign off, not a wishlist.

Masters and migration

Categories, designs, attributes, sizes, suppliers, customers, ledgers, opening balances and live stock are imported and reconciled against your existing books. This is the phase that decides whether your reports are trustworthy, so it gets the most attention.

Parallel run

You bill on ambar 27 alongside your current system for an agreed period, with daily tie-outs on sales, stock and cash. We do not declare go-live until the two agree for a full week.

Cutover and training

Role-wise training by function — counter staff learn billing and selections, cashiers learn settlement, accounts learn planners and returns — with printed SOPs left behind for each role.

Hypercare and handover

A defined support window with the same team that implemented it, then transition to ongoing support. You keep the server credentials throughout.

Operations

What we run, what you own.

AreaHow it works
Data ownershipYour database, on your infrastructure, under your credentials. Full dumps on request at any time, in standard MySQL format — there is no proprietary export to negotiate.
BackupsScheduled database and file backups to storage you control, with a retention policy set during implementation. Restore is tested as part of go-live, not assumed.
UpdatesVersioned releases deployed through a CI pipeline. Schema changes ship as forward-only migrations that run on deploy, with a rollback plan for each release.
MonitoringApplication error logging through Monolog, with alerting on failures. Failed IRN and e-way bill submissions surface as worklists in the application rather than in a log file nobody reads.
SupportA named team that knows your configuration. Support covers the application, the integrations and the deployment — including the server, if you have asked us to manage it.
CustomisationReports, print templates and workflow rules specific to your business are built as part of implementation or a support engagement, and travel with your instance through upgrades.
ExitIf you leave, you keep the server, the database and the data. We hand over documentation and access. Nothing is held hostage.

See ambar 27 on your own numbers.

A 45-minute working session on your store data — your categories, your GST profile, your counters. No slideware.