Beautiful product! Just be aware of the support nightmare that comes along with people trying to install your software in many different environments. I will never, ever create installable software ever again.
As a side note, this is the reason I hate PayPal. They didn't like my refund percentage apparently and simply banned my account. It sucked being treated like some scammer by countless customer support reps just because I couldn't provide tech support to all customers and had a higher refund rate. It's all for the best now though :) Subscription model + Stripe is a godsend.
Stupidly we have this mailing list software running on our production web server (the same one our customers use to access our apps), so we can't do that. I mean I trust the guy to not go in an install a backdoor or delete all of our files (maybe I shouldn't trust him?) but I've always wondered what the liability is there.
Would we basically have to prove he did something malicious if our server crashed the next day or turned into a spam box?
In the meanwhile, I guess you can mitigate risk by making strict permissions for the user they ssh in with. Are they usually manipulating data on the production server, or changing code? If it's just code, you can give them access to a development server and push code to production by yourself after you've done a review.
When people say "ssh access" they usually mean root. The software that's running there, if the server is properly set up, will be running on a restricted account with restricted privileges. Now, granted, even with that there can be quite a bit of damage, but not as much as giving somebody root access to your system.
I think that the proper solution to any paid, self hosted application would be ... to provide hosting for less tech savvy users. Granted, your main selling point is to be self hosted, but you should not alienate people who are interested just by the product itself. And having a less costy per month plan is a great mean to let users try your app before deciding they should takes time or money to educate or hire a sysadmin.
My point is more that it's probably a good thing to provide both webservice and installable app (github, with its github enterprise is a very good example of that, even if way too expansive), to let user choose your product based on what it does instead of what are its requirements and implications.
And b) assuming you have done your due diligence on the developer in the first place, why not trust him with access to your machine? And again - you shouldn't grant him root of course, but a shell account with privileges similar to the application would be fine.
But really - Purchasing a script from some back-alley developer you have no knowledge of and placing it on your production server? That's the reckless part.
The most important thing is to separate the "self installed" users from the ones using the hosted version (which you might try to monetize at some point).
Point self hosted users to a "community" that can help them while users on your system can email you directly.
It's worked out pretty good for us. We have a much shorter response time for hosted users than self installed. We typically answer most questions on both but it helps separate what's most important (hosted users).
You can export the VM from EC2.
A free-to-download "test my environment" script could be a good idea to mitigate some of the installation issues. Write a simple one-file PHP script that a prospective buyer can download for free, and run on their target environment. That script can give them a report showing them what works and what doesn't.
This could save you a lot of post-purchase support requests.
If someone is interested to build something with docker.io please contact me :)
In the Java world there is a concept of a .war file which packages everything up so it's easy to deploy on app servers that handle it like: Tomcat or Jetty.
Also what's wrong with giving out a prebuilt virtual image for a single server install? Github enterprise does this.
I have a Puppet script that sets up deployment on a new server. Puppet does not care how many machines the application is running on. Neither does the load balancer/reverse proxy in front of it; it takes a list of IPs and does its thing across them.
I have never seen an app server do anything that wasn't essentially this process, only with more XML and aggravation.