FrexCore
Menu
ModulesArchitectureCompliancePricing Book a walkthrough

Architecture

Isolation by design, not by query.

Each client runs as a separately credentialed instance behind a filtering edge and a closed perimeter. Separation is enforced by the operating system rather than by a condition in application code, which is the difference between a control you can demonstrate and one you have to trust.

Defence in depth: a filtering edge, a closed origin perimeter, a separately credentialed instance for each client, and encrypted recoverable storage beneath Edge Every request is filtered before it reaches any FrexCore host. DDoS mitigation Web application firewall TLS 1.3 and HSTS Origin perimeter Inbound traffic accepted only from edge ranges. Administrative access by key only, with direct root login disabled and authentication rate limited. isolation boundary acacia.frexcore.com client 1 Web server own server block and certificate Runtime own worker pool, under its own system account Application own tree, releases verified by hash before deployment Database own schema, own credentials, no cross-client query path Background jobs own queue and own schedule pennine.frexcore.com client 2 Web server own server block and certificate Runtime own worker pool, under its own system account Application own tree, releases verified by hash before deployment Database own schema, own credentials, no cross-client query path Background jobs own queue and own schedule tasman.frexcore.com client 3 Web server own server block and certificate Runtime own worker pool, under its own system account Application own tree, releases verified by hash before deployment Database own schema, own credentials, no cross-client query path Background jobs own queue and own schedule Storage, recovery and assurance Encrypted off-site backups Per-client restore Recovery drills on a schedule Audit trail on every record ISO 27001 certified facility
Platform architectureDefence in depth, one instance per clientFig. 1

Separation enforced below the application

Your records sit in a database only your instance holds credentials for, written by a process running under an account only your instance owns. An application fault cannot reach another client, because there is no path for it to take.

Recovery scoped to one client

Backups are per instance and encrypted off site, with a defined retention period and restores exercised rather than assumed. Recovering your Tuesday recovers your Tuesday, with no change window negotiated across a shared estate.

Release control on your calendar

Each instance carries its own application tree, and a release is installed only after it matches a recorded hash. Versions move when your change process says so, not when ours does.

Control summary.

The short version of what a security review usually asks for. The long version, with the configuration behind each line, goes out before a walkthrough so your people can read it rather than listen to it.

Control areaWhat is in place
Tenant separationA dedicated database, a dedicated operating system account and a dedicated process pool for each client. No shared schema, and no query path between clients to get wrong.
Edge filteringDDoS mitigation and a managed web application firewall ahead of every host, with rate limiting on authentication endpoints.
TransportTLS 1.3 with HSTS. Certificates are issued and renewed automatically, so there is no manual expiry to miss.
PerimeterThe origin accepts inbound traffic only from edge ranges. Administrative access is by key, direct root login is disabled, and the host is not reachable by direct scanning.
Access governanceNamed accounts on role-based profiles, with privileged access review raised as recurring scheduled work rather than left to memory.
AuditEvery record carries its own history: who changed what, when, and what the value was before. Reassignment and escalation are written to the record rather than agreed in a corridor.
ResilienceEncrypted off-site backups against a defined retention period, restorable one client at a time, with recovery drills run on a schedule rather than assumed to work.
Supply chainApplication releases are pinned by version and verified against a recorded SHA-256 before a host will install them. An altered or substituted artefact fails closed.
HostingAn ISO 27001 certified facility. FrexCore is not itself certified, and we would rather tell you that than let the logo imply otherwise.

Questions a security review always reaches.

Who can reach my data?
The process running your instance, under its own account, with credentials held by that instance alone. Our operators reach it through named accounts with key-based access and an audit trail, not a shared login.
What happens when you are breached?
Containment is scoped to an instance rather than to a platform, because there is no shared schema for an incident to spread through. You get the facts and the assessment, not a status page.
How quickly can you restore us?
Per-client restore from an encrypted off-site copy, exercised on a schedule. We will give you the measured figure from the last drill rather than a target we have never tested against.
Where does our data sit?
In a named facility, in a jurisdiction agreed before onboarding, with the transfer position documented. It does not move because our hosting arrangements changed.

Recovery, and what we will quote you.

A recovery objective nobody has tested against is a number in a contract. Drills are run on a schedule, and the figure we quote is the one the last drill measured.

Daily encrypted snapshots held off site, an incident, and a restore from the last good snapshot inside the retention window Backup and recovery, scoped to one client one encrypted snapshot a day, held off site incident restore from here retention window Scope one client, restored without a change window negotiated across a shared estate At rest backups encrypted off site, separate from the host that made them Proof recovery drills run on a schedule, and we quote the measured figure from the last one
Backup and recoverySnapshots, retention and restore scopeFig. 2
Restoring one client does not involve a change window negotiated across a shared estate, because there is no shared estate to negotiate across.

What gets installed, and what does not.

The supply chain is the attack path people notice last. Every application release is pinned by version and checked against a hash recorded in the repository before a host will stage it.

An upstream release is compared against a hash recorded in the repository before a host will stage it; a mismatch is refused rather than warned about A release cannot reach a host unless it is the one we recorded Upstream release downloaded, never trusted on arrival Recorded hash SHA-256 committed to the repository Compare on the host, before staging Matches staged and installed Differs refused, nothing is staged A substituted or altered artefact fails closed. The host declines to install it rather than installing it and logging a warning.
Release verificationPinned, hashed, and refused on mismatchFig. 3
An altered or substituted artefact fails closed. The host declines to install it rather than installing it and writing a warning nobody reads.

See it with your own data in it.

Forty minutes on your real situation: what you are running now, where work goes missing, and what a migration would involve. The architecture and control summary goes out beforehand, so your security people arrive having read it. If it is not a fit we will say so on the call.

Book a walkthrough
Email
[email protected]
Call or message
+61 480 010 143
Hours
We answer across African, European and Pacific time zones.