Going live on your own infrastructure: how it is designed

Going live is not part of the alpha. This page describes how it is designed, so you can judge it before you depend on it.

The design in one sentence

In production, your application and its records run on machines your company controls, and by default LobLogix cannot access your production database.

What your company will provide

Machines: virtual machines on Google Cloud or with any other provider, or your own bare-metal servers. A technical colleague or an agency usually arranges this. A provider’s managed Kubernetes service is not needed. See The technology underneath.

What LobLogix will do

Install what the application needs on those machines, and prepare each new version for you.

How a new version will arrive

Nothing is pushed onto your machines. Your side collects a new version only after someone at your company has approved it, and the version collected is the exact one that passed your checks.

Who can see your records

Your company. By default, LobLogix cannot access your production database, and it holds no password or key to it.

If you want LobLogix to help with something in production, you grant that help yourself: to a named person, for a stated purpose, for a set time. The grant is recorded, and it ends on its own.

What LobLogix can see

Only what your side agrees to report, such as whether the application is running and which version it is.

Backups and high availability

Both are part of production, on the business tiers: a three-way database cluster, a hot standby cluster that can sit with a second provider, and continuous backups you can restore to a chosen moment. Preview and Stage hold test records and have neither.

Until then

In the alpha, your application runs in Preview and Stage on LobLogix hosting. See Preview, Stage and Production.