Best for demos, pilots, and self-managed internal rollouts
Local deployment
The current Kanvly build is well suited to local evaluation or internal deployment, with SQLite persistence, Docker support, health checks, and configurable auth/storage integrations.
Local deployment
Running the product end-to-end with your own environment
- SQLite runtime
- Docker and CI
- Configurable auth and storage
Some teams need to evaluate Kanvly in a real environment before wider rollout. The local deployment use case is for demos, pilots, internal proof-of-concept work, and self-managed evaluation where persistence, health checks, authentication options, and storage choices need to be understood clearly.
- Internal pilots where a team wants to test Kanvly with real workflows before broader adoption.
- Technical evaluators reviewing auth, storage, health, persistence, and deployment behavior.
- Small organizations that want a simple path from local demo to managed production-style rollout.
Workflow playbook
How to run local deployment inside Kanvly.
The goal is not to create a complicated operating system. The goal is to make the work, the owner, and the supporting context easy to find every week.
Start with a realistic pilot workspace
Create the same boards, notes, members, and workflows the team would actually use so evaluation reflects real operating behavior.
Add infrastructure only when needed
Begin with the default local path, then add SMTP, OAuth, S3-compatible storage, and Docker deployment when the pilot needs those controls.
Verify operations before rollout
Use health checks, backups, and migration paths to confirm that the deployment can survive normal internal usage before inviting more teams.
- One pilot workspace with realistic boards, notes, users, and settings.
- A deployment note documenting environment choices, auth setup, storage, and known limitations.
- A checklist for health, backup, restore, email, OAuth, storage, and billing readiness.
- A clear decision log for what must be production-ready before wider rollout.
- Day one: run the app, create real state, and confirm persistence.
- During pilot: test sign-in, uploads, notes, boards, calendar, and AI behavior with realistic usage.
- Before rollout: verify health checks, backups, env vars, and external service configuration.
- After pilot: document what worked, what needs hardening, and which team should adopt next.
- Environment setup, operational decisions, and deployment assumptions.
- Smoke-test results for auth, mail, storage, health, and workspace behavior.
- Pilot feedback, rollout blockers, and readiness decisions.
Outcomes to expect
Run the full app locally with persistent state and a production build path.
Configure SMTP, OAuth, and blob storage only when your environment needs them.
Keep the product usable even before third-party infrastructure is wired in.
Use health checks and backups as part of a more serious internal pilot.
Validate workspace behavior before committing to a broader rollout path.
Frequently asked questions
Everything teams ask before they start with Kanvly.
Your team deserves a workspace that gets out of the way.
Create a workspace where notes, boards, calendar planning, and Kanvly AI all understand the same projects, deadlines, and context.
Free to start. Paid plans add larger limits, included seats, sharing, comments, due dates, and more AI usage.