Techservice.cloud acts as an asynchronous infrastructure broker.
Customers buy managed infrastructure through the web app. Techservice provisions and manages isolated servers through provider APIs and connects those servers to the customer dashboard.
Core stack
| Layer | System |
|---|---|
| Web app | Next.js 16 |
| Database and auth | Supabase |
| Background jobs | BullMQ |
| Queue backend | Redis |
| Server providers | Hetzner and Netcup |
| App control plane | Coolify |
| DNS and edge services | Cloudflare |
| Monitoring | Uptime Kuma |
| Resend |
Product model
The product is intentionally narrow:
| Offer | Runtime direction |
|---|---|
| Managed WordPress | CloudPanel or an approved PHP stack |
| Managed applications | Coolify |
| Bare VPS | Raw Ubuntu with a security baseline |
The smaller panel matrix keeps support predictable and prevents the dashboard from becoming a generic cloud console.
Design rule
Every dashboard screen should answer one operational question quickly.
For example:
- Servers: what infrastructure exists and what can be managed.
- Provisioning: what is running, waiting, or failed.
- Marketplace: which managed service should be purchased next.
- Backups: what can be restored and when it last ran.
- Support: what handoff or customer issue is open.
Data principle
Provider data and Coolify data should stay distinct.
Hetzner and Netcup own server-level facts like provider ID, region, plan, CPU, memory, disk, IPv4, and lifecycle.
Coolify owns application-level facts like resources, deployments, environment variables, domains, certificates, databases, and backups.