Why FoxDesk Is Open Source — and Why I’m Launching FoxDesk Cloud

The problem was never a lack of software. We already had email, a help desk, calendars, notes, and spreadsheets. The problem was that a single piece of client work could move through all of them without leaving one reliable record.

A client request arrived in email. Someone took responsibility in a chat. The implementation lived in a ticket or code repository. Time was reconstructed later, and the client report was assembled from memory. Each tool worked, but the workflow did not.

That is why I built FoxDesk around one path: receive the request, assign responsibility, record the work, and show the client a clear result. It is deliberately narrower than an enterprise service-management suite. It is for freelancers and small service teams that work for several clients and need the work record to survive the month.

Why the application is open source

Support systems hold sensitive, long-lived business history. A team should be able to inspect the software, export its data, and run it on infrastructure it controls. The public FoxDesk repository exists for that reason, under AGPL-3.0.

Open source is also a practical constraint on product quality. Installation steps, migrations, release notes, and data formats cannot be hand-waved away when users can see and run the code. Since the first public release in March, the repository has gained a more complete work dashboard, time tracking, client reports, email intake, safer attachments, migration tooling, Kanban views, and application support for 24 languages.

None of that changes with the Cloud launch. The open-source edition is not a trial and it is not being replaced. Teams that want to run FoxDesk themselves can continue to do so from the public repository.

Why Cloud is separate

Running business software is more than starting a container. Someone has to manage updates, backups, email routing, storage, monitoring, tenant boundaries, abuse limits, and billing. Some teams want that control. Others want to start with a workspace and get back to client work.

FoxDesk Cloud is for the second group. It hosts the same core request-to-report workflow, while the platform around it remains private: tenant provisioning, subscriptions, usage controls, and operator administration are SaaS concerns, not features that belong in the public self-hosted repository.

Keeping that boundary explicit matters. I do not want to market a proprietary service as if all of it were open source, and I do not want the public repository filled with hosted billing code that self-hosted users do not need.

What the public beta offers

The beta starts with a 14-day hosted workspace. It does not ask for a card, it does not create a paid subscription, and nothing is charged automatically. If the workflow proves useful, the team can explicitly subscribe later at the introductory price of €9.90 per workspace each month, with no per-user fee.

The useful test is not whether every settings page can be opened. Bring one real client workflow. Let the next request become a ticket, assign it, record the work, and prepare the first report. If that path is clearer than rebuilding the month from email and spreadsheets, FoxDesk is doing its job.

The API is available for integrations and agent-assisted work. The one-approval Agent Worklog flow for turning a completed coding thread into a ticket and time entries is still a controlled pilot. I am not presenting it as generally available until its audits and edge cases have been observed in real workspaces.

Which version should you use?

Choose the open-source edition if operating the server is part of the control you want, you have the technical capacity to maintain it, or the application must stay inside your infrastructure.

Choose Cloud if you want to connect a real client workflow today without taking responsibility for deployment and operations. The product decision should be about how you want to work, not about hiding features behind an unclear license boundary.

I am opening the public beta now because the next useful evidence has to come from real client-service teams. If you are a freelancer, agency, or small IT provider, I will help you set up one workflow in a 30-minute onboarding session and listen to where it still creates friction.