01 · DEFENSE IN DEPTH
More than a perimeter
Network boundaries, host configuration, application access and operational procedures each have a role. Review the layers together so a single control is never treated as a guarantee.
SECURITY & OPERATIONAL RESILIENCE
Security in layers. Resilience by design.
Protect the service. Limit the impact. Keep a path to recovery. Our approach brings infrastructure, application boundaries and operational responsibility into the same conversation.
Six layers. One operating responsibility.
Architecture principles guide each deployment. Controls, monitoring coverage, backup retention and recovery targets depend on the environment and agreed service scope. No architecture eliminates every threat or outage.
02 · ORIGIN TLS
Encryption where traffic arrives
The main webTronex website serves HTTPS at its Nginx origin using a publicly trusted certificate. DNS management and TLS termination are separate responsibilities. Private upstream connections have their own trust boundary; we do not imply every internal hop uses TLS.
03 · WORKLOAD ISOLATION
Reduce the blast radius
The main website uses an application container and a separate database container on a dedicated Docker network. The application runs as a non-root user; neither container is privileged. Containers share a host kernel and are not a guarantee of tenant isolation.
04 · LEAST PRIVILEGE
Access with a purpose
Limit accounts, service permissions and exposed endpoints to the work they need to perform. On the main website, application ports bind to loopback and the database has no published host port. Role reviews and credential practices must be defined for each deployment.
05 · RECOVERY & ROLLBACK
Plan the way back
Treat recoverability as part of a change: capture the previous state, validate in staging, review the difference and retain a rollback path. Backup frequency, retention, restore testing and recovery time and data-loss targets must be agreed for the service; they are not implied by a software licence.
06 · RESPONSIBLE MONITORING
Observe. Investigate. Respond.
Attacks and suspicious access attempts are monitored through the security controls enabled for the environment. The hosting server has active automated abuse prevention for SSH access. This check does not establish equivalent detection for application attacks. Coverage, alert routing and response hours depend on service scope; this is not a claim of a 24/7 security operations centre.
Separate name resolution from application delivery.
Current public DNS observations for webtronex.ca and www.webtronex.ca are consistent with DNS-only delivery: Cloudflare provides authoritative DNS and website traffic reaches the origin directly. This is a point-in-time observation, not an account-wide configuration audit.
Cloudflare DNS
Resolves the hostname
01Visitor
02HTTPS / Nginx
03Application
04Private database
DNS is consulted for resolution; it is not an HTTP relay in this path. The diagram is conceptual and applies to the main website, not every product or client environment.
Fewer mandatory intermediaries. Explicit tradeoffs.
Keeping the Cloudflare HTTP proxy out of this path reduces dependence on its proxy processing. It also means Cloudflare proxy WAF, CDN and proxy DDoS protections are not provided for these DNS-only records. Origin protection, capacity and network-provider resilience still matter. DNS, hosting, connectivity and other vendors remain dependencies.
Architecture is evidence. An uptime story needs records.
Cloudflare’s November 18, 2025 postmortem describes a Bot Management configuration failure, not a cyberattack. That explains why delivery dependencies matter. We have not verified webTronex monitoring records and historical DNS/proxy settings for that period, so we make no claim that every webTronex service stayed available during the incident.
Read the technical sources
Main website observations reviewed October 15, 2026.
Authorized access only.
Attacks and suspicious access attempts are monitored within the configured coverage. Unauthorized access, disruption and attempts to bypass access controls are prohibited. Security testing requires prior written authorization and an agreed scope.
Report a suspected vulnerability through our support channel. Share a concise description and minimal, non-sensitive reproduction details. Do not send credentials or customer data. Please stop testing if you encounter private information.
Contact support