Three services, three responsibilities
Drabsnarg combines public documentation with owner-operated AI infrastructure. Those services share a name, but they should not share an availability requirement or access boundary.
The portfolio presents engineering work. The chat application handles authenticated conversations. A future API would serve authenticated software clients. Treating them separately keeps their responsibilities understandable.
The public website
The portfolio is built as static files and served from Cloudflare Pages. Visiting a project or article does not require a request to the iMac Pro.
That separation means local maintenance and inference downtime do not take the portfolio offline. It also removes the need for model credentials in browser code.
The private application
The proposed path is Cloudflare Access, then Cloudflare Tunnel, then Open WebUI, with inference behind the application.
Access policies and application permissions solve different problems. The edge decides whether a user may reach the application. Open WebUI manages accounts, conversations, and administrative functions.
The remote-access design still requires deployment and validation. A public diagram is a statement of intent, not proof of a working security boundary.
The future API
An API client needs a deliberately supported authentication flow. Browser sign-in should not be assumed to work for command-line tools or automation.
Before adding api.drabsnarg.com, define authorization, credential rotation, rate limits, request limits, and logging. Do not publish the inference endpoint directly as a shortcut.
What belongs in public documentation
Publish component responsibilities, sanitized diagrams, reproducible methodology, and reviewed results. Keep credentials, personal conversations, private addresses, and operational configuration outside public source and build artifacts.
Excluding a page from indexing is not an access-control mechanism. Private material should never enter the public static build.