Most SaaS apps stay browser-only because building a desktop client usually means dealing with native frameworks, packaging, platform quirks, signing, CI/CD, and extra infra overhead. It’s slow, expensive, and frankly not worth it for many small teams.

This CLI abstracts most of that away. It:

- Wraps any existing cloud app into a desktop app - Requires almost zero native code - Runs on Windows, macOS, and Linux (Not fully tested on Linux btw) - Keeps the build pipeline simple (no Electron boilerplate hell)

The goal isn’t to replace your cloud stack, it’s to give your users a native-feeling desktop experience without burning weeks on packaging and deployment.

I initially built this for my own product but decided to open source it because I know a lot of indie devs and early-stage teams face the same friction.

GitHub: https://github.com/deskofy/deskofy Docs: https://docs.deskofy.app

Would love feedback, edge cases you’d like solved, or any integration ideas :D

Comments URL: https://news.ycombinator.com/item?id=45561000

Points: 1

# Comments: 1

I’m curious if there exist any command-line tools (CLI) that allow users to sign up, log in/out, manage subscription / billing, etc, entirely via terminal, without relying on any web UI or browser flow.

I’ve seen many tools that support CLI logins or actions post-login, but still use the web for checkout, payment, plan comparisons, account settings, etc. I’m wondering:

- Does anyone know a tool (open source or commercial) that handles full subscription lifecycle strictly via CLI?

- What are the technical or practical challenges people encountered in trying to build one?

- If this doesn’t exist widely, why do you think that is?

Thanks in advance for pointers or experiences you can share!

Comments URL: https://news.ycombinator.com/item?id=45430760

Points: 1

# Comments: 3

1. Collecting signups and early interest from potential users 2. Analyzing the data using proven theories and algorithms + pre-trained purpose-specific AI models 3. Showing whether your product is on track to succeed, based on targets you set (which can change as users evolve)

Short answer: Server-side encryption.

Long answer: The main application-level encryption key is stored externally in Doppler. Each project’s encryption key is encrypted using this main key. The main key is loaded as an environment variable when the backend server runs. After a set period (X days), the main key is automatically rotated, and all project keys are re-encrypted with the new main key and updated in Doppler.

Project keys are assigned to specific user accounts, so only the assigned users can decrypt them. The application does not use end-to-end encryption because future planned features require server-side encryption and decryption rather than client-side.

Yes, using LLMs can reduce privacy. To address this, we only send the necessary metadata and selected content to the models. In Ask mode, content is only sent if the user explicitly selects it. Edit mode works the same way: only the specifically selected text or code is passed to the model.

Hope this helps :)

What makes Orbivon different is its focus on security and simplicity. Your documents are protected with multiple layers of military-grade encryption, not just disk or database-level encryption, so your knowledge always stays private. The platform avoids cluttered menus and unnecessary features, staying distraction-free and streamlined. While many tools try to do everything, Orbivon is built specifically for founders and developers who want to write, organize, and diagram ideas efficiently.

I’m currently building the desktop application and planning a CLI tool to help automate internal product documentation workflows and integrate with MCP.

Comments URL: https://news.ycombinator.com/item?id=45336016

Points: 1

# Comments: 7