Webcore

PLATFORM / SECURITY

Security is built into every layer.

Isolation, controlled access, TLS, service protection and disciplined update paths matter more than vague security claims. Webcore builds those controls into the way the platform is operated.

IDENTITYRoles · accounts · accessPLATFORMAgents · TLS · updatesWORKLOADSites · services · dataKeep trust explicit.
IsolationRBACTLSService ProtectionUpdatesBoundaries

SECURITY MODEL

Keep access controlled and clearly defined.

Platform security improves when identities, management channels, workload boundaries and operational privileges are explicit. Webcore uses those boundaries to limit what each user, site and system component is expected to control.

01

Least privilege

Give users and systems the access required for their responsibility rather than broad platform-wide authority.

02

Separation

Keep control-plane administration, node management and site-level access as distinct trust domains.

03

Observable protection

Surface certificate, service and protection state so security controls are visible to operators.

ACCESS CONTROL

Scope the interface to the role.

In the WordPress Platform, Platform Admins operate the fleet, Server Admins work within an account scope and Site Admins can be restricted to selected websites. Site ownership and tenant-aware permissions keep downstream users away from unrelated infrastructure.

Platform Admin

Infrastructure and fleet-level authority for Webcore platform operators.

Server Admin

Account-level access for teams responsible for a group of sites.

Site Admin

Site-scoped access without granting wider fleet control.

MANAGEMENT CHANNELS

Routine operations should not depend on unrestricted SSH.

Node provisioning can use temporary SSH access where required, but normal management uses an authenticated node agent and pinned management TLS. Temporary bootstrap credentials are removed after enrolment completes.

Routine updates use node-specific read-only deployment credentials rather than distributing a shared unrestricted repository key across the fleet.

Bootstrap deliberately

Use elevated access only for the initial enrolment workflow when required.

Manage through the agent

Keep normal control-plane operations on an authenticated management relationship.

Limit update credentials

Use node-specific, read-only deployment access for routine release retrieval.

SERVICE PROTECTION

Protect the platform at the service layer too.

Security is not only an identity problem. Webcore also exposes service-level protections such as Fail2ban on hosting nodes, alongside SSL state and application-facing diagnostics.

FAIL2BANObserve and block abusive patterns.

Node-wide intrusion prevention and WordPress-focused protection can be managed as part of the hosting platform.

TLSKeep encrypted delivery visible.

Certificate validity, expiry and HTTPS state are surfaced with the application rather than left as an external assumption.

WORKLOAD BOUNDARIES

One site should not define another site’s trust boundary.

Tenant isolation, site ownership, per-site runtime controls and database separation are part of the WordPress operating model. The same design principle applies across managed infrastructure: customer and application boundaries should remain explicit.

Tenant-aware permissions

Keep account and site access aligned with ownership.

Site-level runtime

Expose useful application controls without handing over the underlying server.

Operational separation

Separate customer workload access from the credentials used to administer platform infrastructure.

SECURITY

Make the trust model clear.

We can review the application, user roles, management paths and infrastructure boundaries together rather than applying a generic security checklist after deployment.

Talk to an Engineer