uptime · 30d
99.97 %
Portal in operation · cbb-1
Sprints, deploys, invoices, incidents and documents in a single console. No chasing anyone on WhatsApp to find out how your project is going.
Every feature spends a month in internal use before it reaches a client. What you see here is the same portal we operate with.
Live view
$ blokis status
all systems operational
uptime · 30d
99.97 %
active projects
4
open tickets
7
billed · month
$ 18.4 k
// recent activity
$ blokis projects ls
4 projects · 2 sprints running
$ blokis billing pending
$4,090 outstanding · 1 due soon
| id | amount | status | when |
|---|---|---|---|
| INV-0241 | $1.480 | paid | 2 days ago |
| INV-0242 | $890 | pending | due in 3d |
| INV-0243 | $3.200 | draft | edit |
$ tail -f /var/log/blokis.log
live streaming from 7 nodes
Signals on one screen
Numbers the client sees
CDN and nodes monitored continuously
Build → CDN edge in production
Database and files · 30-day retention
No tickets, no follow-up meetings
Anatomy of the portal
Pick an area to see what you find inside. It is the same order the real portal menu has.
Live KPIs, recent activity and per-project status on a single screen.
Each product with its active sprint, the commits of the period and recent deploys.
Paid, pending and draft invoices, reconciled automatically with the gateways.
Streamed from the nodes: deploys, crons, service health and rate limits.
Documents, contracts and credentials with row-level isolation for each client.
Technical guarantees
Four architecture decisions that are not up for negotiation, because they are what make opening the portal safe.
Each client only sees their own. The policies live in Postgres, not in the frontend.
No passwords to lose. Rotating sessions with an access log.
Every action is recorded: who, when and on what — and it cannot be edited.
Restores tested every month. Target recovery time under 30 minutes.