Knowing how to set up Redmine correctly from the start saves weeks of reconfiguration later. In fact, Redmine’s flexibility is its greatest strength and its biggest challenge. A blank Redmine installation presents dozens of configuration options, and the order in which you make those decisions shapes how well the system works for your team.
Specifically, this guide walks through the essential setup steps in the right order: installation, project structure, trackers, workflows, user roles, and plugins. By the end, your team has a working Redmine environment configured for real project work not a default installation they have to figure out on their own.
The short answer: Setting up Redmine involves five steps in order — install Redmine on a server (or use Redmineflux Managed Cloud), configure global settings, create your project structure and trackers, set up user roles and permissions, then configure issue workflows. Plugins that extend Redmine’s capabilities Agile boards, Gantt charts, timesheets are added after the core configuration is complete. Each step builds on the previous one; skipping ahead creates configuration debt.
Self-hosted installation requires a Linux server (Ubuntu or CentOS recommended), Ruby, a database (MySQL or PostgreSQL), and Passenger or Puma as the application server. The official Redmine installation guide covers the process in detail. Plan for 2–4 hours of setup time and ongoing server maintenance.
Redmineflux Managed Cloud eliminates the installation step entirely. Specifically, your Redmine environment is provisioned, configured, and running with all Redmineflux plugins pre-installed within minutes. No server setup, no plugin installation, no version management. For teams that want to start tracking work quickly without infrastructure overhead, Managed Cloud is the practical starting point.
After installation, configure the global settings before creating any projects or users.
Go to Administration → Settings and review:
Getting these right at the start avoids reconfiguring notifications and authentication after users are already active. Additionally, without SMTP configured here, assignees will not receive email alerts when issues are created or updated. Consequently, email setup should be your first action before adding any team members.
Trackers are the issue types in Redmine Bug, Feature, Task, Support, and any custom types your team needs. Furthermore, each tracker can have its own fields, workflow, and permissions.
Go to Administration → Trackers → New Tracker.
A standard development team setup uses four trackers:
Create only the trackers your team will actually use. Each additional tracker creates maintenance overhead for workflows and permissions. Consequently, starting with three to four trackers is almost always the right call.
Issue statuses represent the stages an issue moves through from creation to resolution. Go to Administration → Issue Statuses → New Status.
A minimal effective workflow for development teams:
New → In Progress → In Review → Resolved → Closed
Additionally, add a Rejected status for issues the team declines without resolution.
After creating statuses, configure the workflow which transitions each role can make per tracker. Go to Administration → Workflow. Select a tracker and a role, then define which statuses that role can move issues to.
This is where most teams underinvest. In practice, a developer should move issues from New to In Progress but not from In Review directly to Closed without QA approval. Define these constraints here they enforce your team’s process without requiring manual policing.
Redmine’s role system defines what each type of user can see and do. Go to Administration → Roles and Permissions → New Role.
Typical roles for a development team:
Moreover, configure permissions for each role carefully. The most common setup mistake is giving all users Manager permissions this removes the governance that makes Redmine useful at scale. As a result, restrict Manager access to project leads and IT administrators from the start.
Go to Projects → New Project. Fill in:
Add team members under Project → Settings → Members and assign each member their role.
Next, create Versions (Project → Settings → Versions) for your first sprint or release milestone. Versions act as sprint containers when using the Agile Board Plugin and as milestone markers when using the Gantt Chart Plugin.
Redmine’s default installation covers issue tracking, time logging, and documentation. However, for development teams that need agile boards, Gantt planning, timesheet approvals, and workload visibility, plugins add these capabilities without replacing the core system.
The Redmineflux plugins most commonly added at setup:
For teams on Managed Cloud, the Redmineflux team pre-installs all plugins. No additional installation steps are required.
Prefer a guided setup rather than self-configuration? Book a Free Demo → — the Redmineflux team walks through project setup, workflow configuration, and plugin installation in 30 minutes.
Too many trackers. Every tracker needs a configured workflow. Start with three to four trackers. Add more only when there is a genuine need that existing trackers cannot meet.
No workflow constraints. Leaving workflow transitions unrestricted means anyone can move any issue to any status. Consequently, define at least the key transitions (who can close issues, who can move to resolved) from the start.
Giving everyone Manager access. Manager access allows project restructuring, user management, and configuration changes. Restrict this to the people who actually need it typically project leads and IT administrators.
Not configuring email notifications. Without email configured, assignees do not receive alerts when issues are created or updated. Therefore, configure SMTP settings in Step 2 before creating users.
Install Redmine on a server or use Redmineflux Managed Cloud. Configure global settings (host name, email, authentication). Create trackers and issue statuses. Define workflow transitions per tracker and role. Set up user roles and permissions. Create your first project with versions for sprints or milestones. Finally, add plugins for agile boards, Gantt charts, and timesheets as needed.
A self-hosted Redmine installation takes 2–4 hours for server setup, plus 2–3 hours for project configuration. In contrast, Redmineflux Managed Cloud eliminates the server setup project configuration for a new team takes approximately 2–3 hours from first login to first active issue.
In order: global settings (email, host name), trackers, issue statuses and workflows, roles and permissions, first project structure, and team member access. Specifically, add plugins only after the core configuration is stable.
Self-hosted Redmine installation requires Linux server experience. For Redmineflux Managed Cloud, however, you need no technical skills the Redmineflux team handles provisioning and configuration. Project configuration (trackers, workflows, roles) involves no technical skills and runs through the Redmine admin interface.
Overall, Redmine rewards teams that invest in setup. A well-configured Redmine environment right trackers, clear workflows, appropriate role permissions, and the plugins that match your delivery process runs without friction. In short, the setup work done in week one determines how useful the system is in week fifty.
Explore the Full Plugin Suite — add Agile boards, Gantt, Timesheet, and more
Related Reading
