Keystone

The place to hold your organization together.

Keystone is an open-source project management platform designed to give organizations a single place to plan, organize, build, and track their work.

Instead of spreading projects across issue trackers, Git repositories, planning boards, forms, documentation, and chat, Keystone brings the important pieces of an organization's work together around one central concept: the project.

Keystone is being developed by the RIT Society of Software Engineers and is designed from the beginning to support organizations beyond its original environment.

The first Keystone prototype explores a calmer way for organizations to understand and move their work. It is a preview of the product vision rather than a finished application or commitment to a particular implementation.

The experience is centered on projects. Each project brings its work, planning, documentation, development activity, releases, and people into one connected place so the team can understand both the details and the larger direction.

The prototype currently illustrates:

• A clear project overview that surfaces progress, priorities, and work needing attention
• Flexible list and board views for planning and moving different kinds of work
• Roadmaps and releases that connect daily execution to meaningful outcomes
• Repository activity placed beside the project context it supports
• Living project documentation that stays close to decisions and delivery
• Workspace, project, and personal controls for organizations of different shapes and sizes
• Public intake that gives the people who benefit from a project a direct path back to its team

Together, these ideas show the role Keystone could play: not another disconnected tracker, but the shared place where an organization can plan what matters, build it together, and understand what is happening.

Every image below uses the same 1440 × 900 desktop viewport, seeded demo data, and a neutral resting state. Detail images intentionally open one component at a time to show its complete context.

Organization and personal work

Organization home	My Work
Inbox	Members
Workspace activity

Project planning and delivery

Work list	Board
Work item detail	Roadmap
Repositories	Pull requests
Releases	Release detail
Docs library	Document detail
Project activity

Creation and action flows

Command search	Project actions
Create project	Create work item
Create document	Create initiative
Plan release	Invite member

Workspace settings

General	Access and security
Work items	Integrations

Personal settings

Profile	Notifications
Appearance	Security and sessions

Project settings

General	Access
Workflow	Development

Many teams eventually end up with their work scattered across several tools:

• GitHub Issues for bugs and development tasks
• GitHub Projects or another board for planning
• Forms for user feedback
• Discord or Slack for coordination
• Separate documentation systems
• External roadmap and release tools
• Multiple repositories with little project-level context

Keystone aims to provide a cohesive workspace where those pieces connect naturally.

A project should make it easy to answer:

• What are we working on?
• What needs attention?
• Who owns each piece of work?
• What is blocked?
• What are we planning next?
• What milestone or release are we working toward?
• Which repositories belong to this project?
• What changed recently?
• Where can users report problems or request features?

Keystone is designed as a project management platform first.

Tickets are part of the system, but they are represented by a broader WorkItem model that can describe different kinds of work.

A project may contain:

Project
├── Overview
├── Work
│   ├── Bugs
│   ├── Features
│   ├── Tasks
│   ├── Improvements
│   ├── Research
│   └── Maintenance
├── Board
├── Cycles
├── Milestones
├── Roadmap
├── Releases
├── Repositories
├── Documentation
├── Members
└── Activity

This allows development work, infrastructure work, organizational projects, research, and other workflows to live within the same platform.

• Organizations and workspaces
• Projects and project membership
• Project dashboards
• Work items
• Assignees
• Labels
• Priorities
• Comments
• Activity history
• List and Kanban views
• Search
• Milestones
• Cycles and sprint-style planning
• Roadmaps
• Saved views
• Project-level permissions

Keystone will support public-facing intake forms that can be embedded into or integrated with external websites.

Examples include:

• Bug reports
• Feature requests
• Accessibility reports
• Feedback
• Content corrections
• Other project-specific requests

Public submissions enter a dedicated triage workflow before becoming internal work items.

Keystone is intended to integrate closely with software development workflows.

Planned capabilities include:

• GitHub integration
• Forgejo integration
• Repository linking
• Pull request and work-item linking
• Commit references
• Branch references
• Automatic development activity
• Release tracking
• Configurable workflow automation

For example:

KEY-142
Fix authentication callback

Branch
KEY-142-fix-auth-callback

Pull Request
#84 Fix authentication callback

Status
In Progress → Review → Done

Keystone may provide first-class internal Git hosting through Forgejo.

Keystone itself will not reimplement Git transport or repository storage.

Forgejo remains responsible for:

• Git SSH
• Git smart HTTP
• Repository storage
• Git LFS
• Clone, fetch, and push
• Repository maintenance

Keystone provides the surrounding project-management experience and integration.

Projects may use repositories from multiple providers, including:

Forgejo
GitHub
GitLab

This means organizations are not required to move their repositories to use Keystone.

Keystone uses a modular monolith architecture.

                    Users
                      │
                      ▼
                   Traefik
                      │
              ┌───────┴───────┐
              │               │
              ▼               ▼
         React Web       Spring Boot
                              │
                     ┌────────┼────────┐
                     │        │        │
                     ▼        ▼        ▼
                PostgreSQL Authentik Forgejo
                     │
                     ▼
               Object Storage

External Integrations
├── GitHub
├── Discord
├── SMTP
└── Webhooks

The goal is to keep deployment and development understandable while preserving clean internal module boundaries.

Microservices and additional distributed infrastructure will only be introduced when there is a demonstrated need.

• React
• TypeScript
• Vite
• React Router
• TanStack Query
• Tailwind CSS

• Java 25
• Spring Boot
• Spring MVC
• Spring Security
• Spring Modulith
• jOOQ
• Flyway
• OpenAPI

• PostgreSQL
• S3-compatible object storage
• Caffeine for initial application caching

• Authentik for OIDC / SSO
• Forgejo for optional internal Git hosting
• Traefik for reverse proxying and TLS
• SMTP for email delivery

Keystone is designed to provide vendor-neutral application telemetry that can be integrated with the observability stack of the operator's choice.

The application will use:

• OpenTelemetry for distributed tracing and telemetry export
• Micrometer for application and JVM metrics
• SLF4J + Logback for structured application logging
• Spring Boot Actuator for health, readiness, and operational endpoints
• OTLP as the preferred protocol for exporting telemetry

Logs will be structured and include correlation information such as request, trace, and span identifiers where applicable, allowing activity to be followed across application components and integrations.

Although Keystone is initially being developed for use within RIT SSE, the architecture is designed to support multiple independent organizations.

Keystone
│
├── Organization A
│   ├── Members
│   ├── Projects
│   └── Integrations
│
├── Organization B
│   ├── Members
│   ├── Projects
│   └── Integrations
│
└── Organization C
    ├── Members
    ├── Projects
    └── Integrations

An organization acts as a tenant and security boundary.

This creates a path for Keystone to eventually support:

• Student organizations
• University departments
• Academic institutions
• Open-source communities
• Development teams
• Nonprofits
• Small organizations
• Other collaborative groups

Keystone is intended to support multiple deployment models.

Organizations can operate Keystone on their own infrastructure.

A future managed Keystone service may provide hosted workspaces without requiring organizations to operate the infrastructure themselves.

Larger organizations or institutions may eventually operate isolated Keystone deployments with their own:

• Identity provider
• Domain
• Storage
• Database
• Infrastructure
• Administrative policies

The open-source application remains the foundation across these deployment models.

Security is treated as a core architectural requirement.

The design includes:

• OIDC-based authentication
• Server-side authorization
• Organization and project RBAC
• Secure HTTP-only sessions
• CSRF protection
• Input validation
• Rate limiting
• Public-intake abuse protection
• Webhook signature validation
• SSRF protection
• Audit logging
• Least-privilege integration credentials
• Private object storage
• Off-site backups

Authentication and authorization are intentionally separated.

The identity provider determines who a user is.

Keystone determines what that user may access.

Security issues should not be reported through public GitHub Issues. See SECURITY.md once the project's security policy is published.

External integrations are designed to fail independently.

A failure involving Discord, GitHub, Forgejo, SMTP, or another integration should not prevent core project-management operations from succeeding.

For example:

Create Work Item
      │
      ▼
PostgreSQL Transaction
      │
      ├── Work item saved
      └── Event recorded
              │
              ▼
      Background Processing
        ├── Email
        ├── Discord
        ├── Git integration
        └── Webhooks

PostgreSQL remains the authoritative source of application state.

Keystone intentionally starts simple.

Initial architecture:

React
  │
Spring Boot
  │
PostgreSQL

Supporting services are introduced only when they solve a real problem.

For example, Redis may eventually provide:

• Distributed caching
• Shared rate limiting
• Real-time event fanout
• High-volume session storage
• Temporary distributed state

Until those requirements exist, PostgreSQL and local application caching are preferred.

The goal is not to build a distributed system for the sake of having one.

Keystone is currently in the architecture and initial development phase.

The first major development target is the project-management core:

• Application foundation
• Authentication
• Organizations
• Membership
• Projects
• Work items
• Comments
• Labels
• Priorities
• Workflows
• List view
• Kanban board
• Search
• Public intake
• Notifications
• Audit logging
• Repository linking
• GitHub integration
• Forgejo integration

Later phases are expected to introduce:

• Cycles
• Milestones
• Roadmaps
• Releases
• Saved views
• Automation rules
• Project analytics
• Repository provisioning
• Documentation
• Native repository browsing
• Extended development integrations

The roadmap will evolve as the project enters active development.

The intended repository layout is:

Keystone/
├── web/
│   └── React + TypeScript frontend
│
├── server/
│   └── Spring Boot backend
│
├── api-client/
│   └── Generated TypeScript API client
│
├── infra/
│   └── Development and deployment infrastructure
│
├── docs/
│   ├── architecture/
│   ├── adr/
│   ├── deployment/
│   ├── diagrams/
│   └── runbooks/
│
├── CONTRIBUTING.md
├── SECURITY.md
├── LICENSE
└── README.md

Architecture decisions that significantly affect the system should be documented through Architecture Decision Records under docs/adr/.

Development setup instructions will be added as the initial application structure is established.

The goal is for local development to eventually require little more than:

git clone https://github.com/rit-sse/Keystone.git
cd Keystone

followed by a documented local environment bootstrap process.

Development dependencies such as PostgreSQL, Authentik, Forgejo, and supporting infrastructure will be containerized where practical.

Keystone is open source and contributions are welcome.

Contribution guidelines, development setup, coding conventions, testing requirements, and pull request expectations will be documented in CONTRIBUTING.md.

Before making major architectural changes, contributors should review the technical design and relevant Architecture Decision Records.

Good first contributions will eventually be labeled through GitHub Issues.

Technical documentation will live under docs/.

Planned documentation includes:

• System architecture
• Architecture Decision Records
• API documentation
• Data model documentation
• Deployment guides
• Development setup
• Security documentation
• Operational runbooks
• Editable architecture diagrams

Keystone is licensed under the GNU Affero General Public License v3.0.

See LICENSE for the complete license terms.

The AGPL allows Keystone to remain open source while also covering modified versions operated as network services.

Commercial use of Keystone is permitted under the terms of the license.

Keystone began as an effort within the RIT Society of Software Engineers to create a better way to manage organizational projects, development work, requests, and collaboration.

The project is being designed with the hope that the same platform can eventually be useful to organizations far beyond its original environment.

Keystone

The place to hold your organization together.