Roll out Kanvly without overbuilding too early.
Kanvly is designed to work well both as a local product evaluation and as a managed internal rollout, with a clear path from simple setup to infrastructure-backed operation.
Default runtime
Kanvly runs as a Next.js application with persistent SQLite storage by default. That makes it practical for local development, internal pilots, and early production-style rollout without extra infrastructure on day one.
- Persistent workspace state
- Local-first evaluation
- No forced third-party setup
- Fast path to internal pilots
Authentication and access
Password auth works out of the box. Google, GitHub, and OIDC can be added when your environment is ready. Workspace membership, private notes, and private boards remain part of the core access model.
- Email and password by default
- Optional Google, GitHub, and OIDC
- Workspace-aware membership
- Visibility controls built into product logic
External services
SMTP can be connected for transactional email, while S3-compatible storage can be used for avatar uploads and related assets. Kanvly remains usable even before those integrations are configured.
- SMTP for reset and operational email
- Preview outbox fallback when mail is not configured
- S3-compatible avatar storage
- Local behavior that degrades cleanly
Operational behavior
The product includes health checks, rate limiting on sensitive flows, support intake persistence, and production build support. Docker packaging is available for containerized environments.
- Health endpoint
- Rate limiting
- Support intake persistence
- Docker-ready runtime
Recommended rollout path
The cleanest path is to start small, validate the workspace model with real use, then add infrastructure only when it becomes necessary.
Evaluate locally
Run Kanvly with local persistence, create a workspace, and validate how boards, pages, notes, and member flows behave with your real process.
Pilot internally
Roll out to a limited team, test permissions and visibility, and confirm that notes, docs, boards, and notifications fit daily operations.
Add infrastructure
Connect SMTP, provider auth, and object storage only when those systems are required by your environment or procurement process.
Standardize operations
Move into Docker-backed deployment, health monitoring, policy review, and formal security or DPA review when the product becomes a shared internal standard.
What the deployment surface includes
Persistence
SQLite by default
SMTP or local preview outbox
Auth
Password, Google, GitHub, OIDC
Storage
Local uploads or S3-compatible object storage
Packaging
Production build and Docker runtime
Health
/api/health for smoke checks
Before a wider rollout
- Validate workspace roles, private notes, and private board behavior with real team members.
- Decide whether transactional email should stay in preview mode or move to SMTP.
- Review whether your environment needs provider auth, SSO, or external storage from day one.
- Use the security, privacy, and DPA pages during procurement or internal approval.
- Adopt Docker and health checks when the product becomes part of a repeatable managed environment.