What are the system requirements (hardware and software) for self-hosting FogBugz 8?
FogBugz System 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.
What we run:
For FogBugz On Demand, our web servers are all Windows Server 2003 64-bit.
Windows editions and versions we test on
Additional Windows versions and editions we support:
Unsupported but known to have worked:
Unsupported Windows editions:
We test on the last two server releases of:
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:
On Windows servers, FogBugz requires IIS 6 or 7 with ASP.NET and .NET 2.0.
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 (Express versions are supported, but note that they have database size and memory usage limits)
Support for SQL Server 2000 only extends as far as FogBugz 7.1.16.
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:
Additional supported versions:
5.5 (FogBugz 8 only)
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.
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.
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.
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.
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.