We've set up a GitHub service hook, so you can use your public and private GitHub repositories to deploy to AppHarbor. The setup process is very simple: Go to GitHub, enter the "Admin" section of your repository and set up the repository by following the instructions under the "AppHarbor" service.

Remember that if your repository is private you should add the "apphb" user as a collaborator on your repository to allow us to fetch the code.

If you're using GitHub organizations for your repository hosting you can simply add the "apphb" user to an organization team that has access to the repository.

We'd like to say thanks to Krzysztof Kozmic for providing a great stop-gap solution until now. He recently launched a GitHub connector that connects your AppHarbor application with a GitHub repository and allowed for the same functionality on public repositories. While we always welcome these initiatives in the ecosystem surrounding AppHarbor, we thought it was really our job to make this integration directly with GitHub.

With this release we now support a number of options for hosting code and deploying to AppHarbor. If you prefer Git, you can use either Bitbucket, GitHub or AppHarbor. If Mercurial is your favorite tool we recommend using Bitbucket. If you have open source projects on CodePlex, you can easily connect them with AppHarbor as well. And finally, if none of the above are the right choices for you, please feel free to take advantage of the build API.

We are always looking to add high-quality add-ons to the AppHarbor add-on catalog. Today we are excited to announce that SendGrid is now available as an add-on.

SendGrid provides easy-to-use email sending facilities for your AppHarbor-hosted application. SendGrid takes care of all the nasty details that ensures that your emails reach their intended recipients so that you focus on building great applications. SendGrid also provides comprehensive email analytics to let you track opens, clicks, bounces, invalid email addresses and spam reports.

Go add the SendGrid add-on to your applications right now. AppHarbor will automatically inject the necessary system.net/mailSettings elements in your web.config and you'll be sending emails through SendGrid without any additional configuration required.

We have migrated AppHarbor SQL Server and MySQL databases to the add-on model. This will not affect running applications, nor will it have any near-team implications. Going forward, you need to be mindful of how you configure your application. Read on below.

The reason we are introducing this change is to have a unified process for adding resources to AppHarbor applications. This will greatly simplify our code and will make provisioning and billing simpler for developers using AppHarbor. By decoupling databases from the main AppHarbor application, it will also be easier for us to improve the database offering out of band from what goes on with AppHarbor.

The migration will not affect running applications, and current connectionstrings will continue to work. The alias-based connectionstring replacement is also still working for databases with aliases currently configured.

As is the case with connectionstrings we used to insert, the new ones are not compatible with Entity Framework. To properly configure an application using Entity Framework, you have to piece together your own connectionstring using the values in SQLSERVER_URI (and similar for MySQL) which AppHarbor will insert into the appSettings section of your web.config.

On a related note: Going forward, it's extremely important that configuration information such as connectionstrings and configuration for other provisioned add-ons is always read from the values inserted by the platform into web.config and not hardcoded in either code or web.config. This is because AppHarbor may dynamically change the configuration of a running application and redeploy it (to force a configuration reload). This becomes relevant if, for example, a database server goes down, and we need to move the databases and update all affected applications with the new configuration. Note that we don't expect this to become a regular occurrence, but we want to make sure developers engineer applications to tolerate such updates.

If you have any questions on how handle this migration or if you experience problems, feel free to drop us a line at support@appharbor.com.

Today we're featuring Todo.my built by Nikunj Dhawan.

What is Todo.my?

Todo is an easy to use Task Management website, I currently have around 75 registered users.

Why did you choose AppHarbor?

AppHarbor is beautiful, I can deploy my new version in less than 15 seconds. Best part is it can be linked through BitBucket which makes it very easy.

Todo.my uses MongoDB for persistence and on AppHarbor a MongoDB database is easily provisioned throught the add-on program.

Once I get more users, scaling up will be as easy as clicking few buttons.

Which technologies is Todo.my built on?

Todo is built on ASP.Net MVC 3 using the Razor view engine. It uses jQuery and KnockoutJS to a great extent and MongoDb for data storage.

How has AppHarbor worked for you so far?

AppHarbor is WOW, I have been using Azure and you are absolutely correct when you say that AppHarbor is "Azure done Right".

I never thought, deploying new versions of my application could be so easy, and the rollback feature is great if I discover a problem with a new build.

How often do you deploy new versions?

When being developing actively, several versions a day -- otherwise, at least once a week.

What did you like the best? Where could we improve?

I loved everything I tried with AppHarbor so far. I'd love to get brackground jobs. Currently I am scheduling my tasks through a third party web cron manager.

Anything else?

Thank you so much for providing such a GREAT platform!

Thanks Nikunj, for taking the time to answer our questions.

Our Copenhagen Office is expanding rapidly and yesterday we were joined by Niels Hanberg. Niels used to work with Rune and Troels and we're excited to have him work with us at AppHarbor

Interested in joining Niels, Mark and the rest of the AppHarbor team? We're looking for more great engineers.

A switch for setting applications in maintenance-mode while performing upgrades to app databases and such, has been a common request for a while. In general, we think you should try to build your application to allow for smooth upgrades without scheduled downtime, but with that said, we are happy to report that you can now place an AppHarbor application in maintenance mode with ease. Best of all, we did not have to lift a finger to make this happen. The feature was built by Drew Miller using AppHarbor application build URLs.

To place an application in maintenance mode, copy the build URL from the application dashboard, paste it in to maintman.apphb.com and hit "Turn On". MainMan will now post a message to your application's build URL. This makes AppHarbor download an archive containing a static App_Offline.htm page generated by MaintMan. This page gets speedily deployed and your application is now in maintenance mode. Once maintenance is complete, you simply deploy a previous commit from the AppHarbor dashboard or push a new one.

You could, of course, add an App_Offline.htm to your primary repository and push "going into maintenance mode" commits to achieve a similar effect. This is tedious though, and will crud up your revision history with commits unrelated to the development of your application.

Drew has made the MaintMan source code available on Githhub. In case you don't trust Drew with your build url (he could hoard it, for example, and use it to randomly push code that Rickrolls users), you can clone the repository and push your own, private MaintMan installation to AppHarbor.

Have an idea for other interesting uses for the application build URLs? Check out the documentation and let us know if you come up with something cool.

Since launching add-ons a few months ago, we have had a steady stream of interest from additional add-on providers. We have already added IndexTank (real-time full-text search) and today we're announcing Blitz.io.

Blitz.io is a load-testing-tool as-a-service and it's a great way to determine whether you need to take advantage of our recent scaling announcement. To start using Blitz, select the AppHarbor application you want to load-test and add the add-on. Then follow the link to Blitz and you'll be automatically signed in. Once there, hit "Play" to start load-testing your AppHarbor application.

To generate the graphs included below I issued this command:

 --region virginia --pattern 1-250:60 appharbor.com

This tells Blitz to hit appharbor.com with requests from their Virginia data center (where AppHarbor servers are also located) over a period of 60 seconds, starting with 1 user and increasing to 250 concurrent users.

From the charts we can determine that appharbor.com does pretty well up to around 200 concurrent users, typically responding in less than 10ms. Around 52 seconds into the run, at 200 concurrent users, response times rise. On the bottom graph we can see the proportion of timeouts (orange line) increasing at the same time.

Blitz also provides a friendly summary of highlights (bottom screenshot), suggesting we use redis, memcached – both AppHarbor add-ons – or varnish to cache data. The conclusion is that if we want to support more that 186 users concurrently browsing appharbor.com then we should scale the application. Good thing AppHarbor makes this incredibly easy.

Want to build and add-on for AppHarbor? Here's a guide you can follow, including plenty of sample code.

Today we're featuring DangDeal built by Karthik Balasubramanian. Karthik is bootstrapping DangDeal.

What is DangDeal?

DangDeal is an auction site where a penny bid costs... wait for it - a PENNY! All the other penny auction sites sell bid packs and each penny bid costs around $.70, meaning that an item selling for $10 yields the site 1,000 bids or $700 - a lot to collect on a $50 gift card! On DangDeal users express interest by buying-in to the auction - then each bid costs only a penny.

DangDeal needed a stable, scalable platform to handle high volume of concurrent users - at a penny a bid we expect to get pounded! Our service is founded on integrity - a penny bid costs a penny. We rely on AppHarbor to back that integrity with performance and scale, allowing every bid to count.

Why did you choose AppHarbor?

For other applications, we have used Amazon EC2 with HAProxy/nginx and Azure. The original promise of EC2 (scale and cost) fell well short with a significant amount of our development time wasted on administration and deployment. Azure deployment has proven painful and we wanted to focus on development.

After reviewing AppHarbor it seemed a no-brainer. After a brief test we were sold and fully committed to AppHarbor. The ease with which you can deploy is amazing (and the way it should be!).

Which technologies is DangDeal built on?

DangDeal is built on ASP.NET Razor Web Pages, Chirpy Visual Studio Add In, MS SQL Server, Dapper.net, and Memcached on Memcacher.

How has AppHarbor worked for you so far?

On the technology side, it has been awesome. But the highlight is on the support (and human) side. We have had few queries and all of them were answered within few minutes. AppHarbor's terrific service compounds our savings by really limiting our operational commitments and allowing us to really focus on our product.

How often do you deploy new versions?

In our current phase, we deploy multiple times a day (why wouldn't you given how easy it is). We must be as responsive to our new users as AppHarbor has been to us and we know that the rapid improvement to DangDeal is critical to our success.

What did you like the best? Where could we improve?

Build and testing integration with version control has been around for a bit, but coupling it with deployment is innovative. At the risk of sounding redundant, the fanatic support has is what we like the best.

Suggestions for improvements:

1. Automatic deployment as an option rather than the only way - We like this feature on Azure as well as on Google App Engine. On a new push, your code is sandbox'ed in a staging environment and you can choose when to deploy. This can be simulated on AppHarbor by having two applications and with some git magic, but it should be incorporated into the platform.
2. Durability of the version control platform - There isn't much documentation around whether your git repo can be used as the primary remote repo. We are using unfuddle for remote repo and push to AppHarbor for deployment.

Anything else?

Other than thanking the AppHarbor team for putting out this fantastic product, we would love for readers to head over to www.dangdeal.com and try it out.

Thanks Karthik, for taking the time to answer our questions!

We have always touted seamless scaling as a reason to host your app on AppHarbor. We are excited to announce general beta-availability to all our users! Scaling was actually built into the platform almost from the beginning, but only appharbor.com and a few test sites have been deployed to multiple application instances until now. Check out this January blog post to get an idea of how we scale your applications.

We are launching scaling with a few limitations: You can only add one additional instance (contact us if you require more) and you have to enter valid credit card details on your account. The good news is that we won't start charging you just yet, and we promise to announce well in advance before doing so. Once you have entered your credit card details, you can add an additional instance in the application interface.

Adding additional instances gives your AppHarbor application a higher maximum request throughput. On top of that, when you add additional instances, we make sure those instances run on redundant servers. This makes your application tolerant of individual application server failures (if your application has only one instance and if the underlying server crashes, the AppHarbor platform will redeploy it, but it may take some time). We are currently investigating running application servers in multiple AWS availability zones for even greater resilience.

There are some interesting implications of running your application on multiple instances. The most pertinent limitation is that you can't expect consecutive requests from the same client to be served by the same instance (i.e. no "sticky sessions"). This means you should never rely on any state stored on individual instances. We recommend using Amazon S3 instead of the local file system for any storage requirements other than caching. caching minified .css and .js on the instance filesystem is acceptable, for example, and does not require use of S3. For session state, we recommend trying the Memcached provider in combination with our Memcacher add-on. We have written a guide on setting up the Memcached provider on AppHarbor.

If your web.config does not include a machineKey element or if the machineKey is configured to AutoGenerate, we will automatically insert pre-generated machinekeys. This means that encrypted forms-authentication cookies generated by one application instance will also be accepted by other instances hosting your app. We always insert the same keys for your application so that sessions are valid across deploys.

Go add your additional free instance right now and help us shake out any scaling bugs. Scaling happens from the Settings dashboard on your AppHarbor applications. If you encounter problems, drop us a line at support@appharbor.com.

We're happy to announce AppHarbor integration with CodePlex -- Microsoft's open source code-hosting site. The integration is currently live on CodePlex (under "Project Summary & Details") and here's the CodePlex announcement.

We have written a short guide on how to set up your CodePlex project to deploy automatically to AppHarbor.

We are really happy with the way Mercurial support using Bitbucket has worked out for AppHarbor users, and were excited to now support Subversion, Mercurial (again), and Team Foundation Server (!) through this collaboration with CodePlex.

Go ahead and give it a whirl, and drop us a line at support@appharbor.com if you encounter any problems.