I'm trying to determine a way to distribute software updates for a hosted/on-site web application that may have weekly and/or monthly updates. I don't want the customers who use the on-site product to have to worry about updating it manually I just want it to download and install automatically ala Google Chrome. I'm planning on providing an OVF file with Ubuntu and the software installed and configured.

My first thought on how to distributed software is to create six Apt repositories/channels (not sure which would be better at this point) that will be accessed through SSH using keys so if a customer doesn't renew their subscription we can disable their account:

  1. Beta - Used internally on test data to check the package for major defects.
  2. Internal - Used internally on live data to check the package for defects (dog fooding stage).
  3. External 1 - Deployed to 1% of our user base (randomly selected) to check for defects.
  4. External 9 - Deployed to 9% of our user base (randomly selected) to check for defects.
  5. External 90 - Deployed to the remaining 90% of users.
  6. Hosted - Deployed to the hosted environment.

It will take a sign off at each stage to move into the next repository in case problems are reported.

My questions to the community are:

  1. Has anyone tried something like this before?
  2. Can anyone see a downside to this type of a procedure?
  3. Is there a better way?
  • 3
    Just curious, but whats to stop someone from downloading the update from your repository, and then re-publishing it via P2P networks? I would also note that if your going to have your customers add your repositories to their sources.list file, you may want to mention Apt-Pinning for their own security. Otherwise someone could insert a malicious libc to your repo and your customers would automatically update to it. Commented Apr 2, 2011 at 7:53

7 Answers 7


Overall, I love the approach. Piracy issues can't be countered anyway, whether over traditional distribution or automated, and you can avoid the inconvenience of a licensing scheme.

You might get problems with the random selections. Is a customer picked to be an early adopter for the whole duration of your business relationship? If not, how can a downgrade from external 1 to external 9 be realized?

  • My plan was to have it be a random selection every month or so and if you were in the external 1 group one period you were except from the group for several periods. Commented Aug 3, 2011 at 12:48
  • You might run into issues with that, since it is pretty much unpredictable which user has which upgrade and who needs to be hotfixed. Say you have a bug in external 1 and a user just dropped out of external 1, you need to push the hotfix all the way to external 90. Maybe you could just ask the customers who would like to be an early adopter?
    – thiton
    Commented Aug 5, 2011 at 8:01

Have you thought about general licensing and phone home type protection for your software?

The issue I see here (without any licensing) is that I can pay for a month, stop, then just keep running on this version. Sure its old, but its free. This loophole will be exploited by at least some people

If you already have licensing, then just have simple unprotected repositories with the software requiring checking the license before running

  • 2
    Thanks for the feedback. In order to reduce the pain to get people to use this my plan is to have the software run in full feature mode for 30 days then require the customer to purchase at least a years worth of updates and support to bring it out of a "crippled" mode. If they choose to stop paying for the product after that time they can and they just won't get the updates or our awesome tech support. :-) Commented Mar 28, 2011 at 12:09
  • @TheLQ: I don't see that as a problem: Having access to the repositories is what you're paying for anyway. If you stop paying, you don't get updates that fix security issues and bugs or add features. That seems like a perfectly sane business model to me.
    – greyfade
    Commented Jul 26, 2011 at 0:39

I don't know enough about your software and/or the nature of your customers, but in many places updates are not installed without being tested. Many companies use a license key that will timeout. Allow them to download the update and initiate manually. Auto updates are convenient, but sometimes users don't like surprises.


Take a look at the Sparkle framework for OS X, it does a very similar thing to the Chrome update mechanism but provides user feedback so they can skip the update or do it later. I've had applications update on me and change functionality that I needed as was, always best to at least ask the user.

I like the apt idea though, makes sense to do it that way, it's simple and really, really well tested at this point.


I know of a company that is doing almost exactly what you have described. (Fewer tiers than you have described, and I don't know how they're authenticating.)

The largest problem they had is that some customers block internet access from their appliance. That means those customers are just locked down to the version that they installed. Maybe that's fine. I think they discussed opening up firewall rules with some of those customers. Others just upgraded manually.


If i was to do it I would do it based on IP address. So when they come to download their ip address has to be on the allowed list to connect to that server otherwise they can't download. It sucks if they don't have dedicated ip but unlikely from what it sounds like you're talking about if it's server based if it's for work stations then you may be better off setting them up with there own apt server inhouse and then that downloads a copy via cron job or something over ftp and so on once a week and then there workstations download from there really up to you.


This is a good seasoned approach.

Some pitfalls to consider:

  • You may not always want to to go 1 percent, 9 percent, 90 percent. Your customers may not be homogenous, meaning you might want to start specialising, say, by region, by device type, etc. in which case a distribution by 1, 9, 90 percent globally no longer makes sense.

  • Having a single repository for 90 percent of your users introduces hotspotting - that server will experience the bulk of requests, which means it will be the first to die in the event of a traffic surge, causing an outage for 90 percent of your users. Redundancy helps, of course, but that introduces more expense overall.

  • You may have a workflow where certain features are ready for distribution to 90 percent of all users, but a global update will cause features not ready for 90 percent adoption to hit production, introducing botttlenecks in your dev workflow. A fixed distribution will not be able to handle these issues effectively, forcing you to handle this at the application level.

A way to correct for that is by keeping multiple copies of production repos on different servers, place a configurable load balancer in front of it, and then carefully update your production repos incrementally on a rolling basis. In other words, treat all repos as eventually wanting to be the same, but configure traffic so the percentage of users reading from a server is changeable.

The benefit is you can configure distribution of requests at will using your load balancer, you can scale horizontally better (all of your servers can start serving the same repo proportionally if all features are ready for 100 percent adoption), and, depending on how your team's workflow is and your need for region specific updates, you can eventually allow certain features to be available right away without worrying about the other features.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.