Question

What are the system requirements (hardware and software) for self-hosting FogBugz 8?

Answer 1

FogBugz System Requirements

Hardware/VM Requirements

2GB RAM minimum. 4GB RAM preferred.

We've never encountered an install that needed a beefier processor. It's very likely that, if you have enough RAM, whatever processor you have is fast enough. Naturally, if you've upgraded a horrendously old machine with a bunch of RAM, there's a limit.

Operating Systems

What we run:

For FogBugz On Demand, our web servers are all Windows Server 2003 64-bit.

Windows

Windows editions and versions we test on

• Windows 2003 32 Bit Version 5.2.3790
• Windows Server 2003 64 Bit Version 5.2.3790
• Windows 2k8 R2 64 Bit Version 6.1.7600

Additional Windows versions and editions we support:

• Windows Server 2003 Standard/Enterprise/Datacenter Edition

Unsupported but known to have worked:

• Windows Small Business Server 2003/2008 (with caveats)
• Windows XP 32 Bit Version 5.1.2600
• Vista 32 Bit Version 6.0.6000
• Vista 64 bit 6.0.6001
• Windows XP 64 Bit 5.2.3790
• Windows 7 64 Bit 6.1.7600

Unsupported Windows editions:

• Windows Server 2003/2008 Web Edition

Linux

We test on the last two server releases of:

• Ubuntu LTS (10.04 & 12.04, 32 Bit)
• RHEL (5 & 6, 32 Bit)
• Fedora (16 & 17, 32 Bit)
• CentOS (5.8 & 6.2, 32 & 64 Bit)
• Debian (5 & 6, 32 Bit)

Note: GDI+ must be installed in order for users to upload profile pictures. Please read Profile Pictures on Linux / Unix for additional details.

Additional versions and distros we support:

• Many prior versions of the above distros will work, but we do not have a comprehensive list.

Web Server

On Windows servers, FogBugz requires IIS 6 or 7 with ASP.NET and .NET 2.0.

Databases

Please note that you should have a fair amount of experience in your chosen database system to run FogBugz. It can certainly run with no problems for years, but FogBugz has a way of becoming central to the work of a team, and a failed/corrupted database should be something you can handle, because it can happen.

What we run:

For FogBugz On Demand, our database servers run both Windows Server 2003 64-bit and Windows Server 2008 R2 64-bit. The servers run SQL Server 2005 if they're on Windows Server 2003, and they run SQL Server 2008 R2 if they're on Windows Server 2008 R2.

Microsoft SQL Server

Make sure you're shrinking your transaction logs.

Versions we test on:

• Microsoft SQL Server 2005
• Microsoft SQL Server 2008
• Microsoft SQL Server 2008 R2
• Microsoft SQL Server 2012

Minimum Version:

Microsoft SQL Server 2005 (Express versions are supported, but note that they have database size and memory usage limits)

Not supported:

Support for SQL Server 2000 only extends as far as FogBugz 7.1.16.

MySQL

Here's a list of gotchas you might want to review if running MySQL. We also have a sample my.cnf for MySQL 5.1 (with some restrictions).

Minimum version:

Community 5.0.45

FogBugz 7.3.9 can only be run on MySQL versions between 5.0.45-community and 5.1.59-community. You can find older MySQL versions than the current GA release (5.1.58 as of this writing) here.

Versions we test on:

• 5.0.77
• 5.0.41a
• 5.0.95
• 5.1.41
• 5.1.61
• 5.1.63
• 5.5.24

Additional supported versions:

5.5 (FogBugz 8 only)

Access

Official support of Microsoft Access databases was discontinued as of FogBugz 7.3.6, and the option is entirely removed in later versions. Use of MS-SQL's database import tools is not encouraged as it can lead to unexpected results. The recommended conversion technique is to use Easy From's ESF Database Migration Toolkit to convert from Access to SQL Server, and is quite easy, so we strongly recommend doing so! MS has also released a general purpose server migration page to help you migrate data between databases, which should eventually point you to the Microsoft SQL Server Migration Assistant for Access. This has not been tested extensively, but it is an alternative to the ESF Migration tool.

Effective Limits

Disk Space

The bulk of the size of the FogBugz database is made up of email events and attachments (usually from incoming email, not from files attached from the FogBugz interface). If you are not corresponding with a user base that's likely to submit large attachments, it's very unlikely that you'll amass 1GB per year of usage.

Responsiveness

Our internal FogBugz installation has sub-second response times for page loads and wiki edits, with a 150GB SQL Server 2005 database. Searches currently take significantly longer, but we're working on search improvements.

We've seen intermittent issues with running MySQL databases in the 30-50GB range, but by the same token we have many clients running MySQL with larger databases than this. If you're going to run FogBugz against MySQL, especially with large attachments coming in via email, it's recommended that you have significant experience with MySQL administration and tuning.

Browsers

See "What web browsers does FogBugz support?".

Number of Users

There are still practical limits on the scale of an installation, particularly around user administration. We have plenty of happy customers at the 250+ user level, but they're happy because they've let us help them understand the trade-offs involved in using a team-focused solution at that scale.

See Also

• Will FogBugz run on a cloud server?
• Is it OK to install Kiln and Fogbugz on the same server?

Answer 2

If you are actually advising your customers to shrink their transaction logs with SQL Server you are doing them a disservice. This is widely regarded as a bad practice, (See: http://sqlskills.com/BLOGS/KIMBERLY/category/Transaction-Log.aspx for best practices guidance). If your transaction logs are set to an appropriate size for your environment and you are doing transaction log backups with an appropriate frequency for your environment then they should seldom grow in size.

The issue with SQL Server is the number of IT people who get tasked with maintaining them who have no database experience. I usually point our customers over to Ola Hallengen's excellent Maintenance Solution, (http://ola.hallengren.com/), as a perfect starting point.

Not trying to be overly critical, I just see this advised often and it really is a bad idea.