Have you considered a virtual machine appliance? That’s how GitHub does it for GitHub Enterprise, and how Microsoft does it for their beta software (particularly early stage beta).

This provides a few different advantages:

1. Restricts client access to code. In GitHub’s case, this means that their non-open-sourced core components remain out of the sight of clients, and there’s no fuss with NDAs or whathaveyou. The appliance is deployed, everything runs automatically, and it’s all accessed and administered via the web interfaces.
2. Ensures a stable, controlled deployment environment. Nothing’s more of a pain than to deploy to someone else’s server, only to find out that they’re running an old version of PHP and can’t upgrade, or worse, they’re running an old version of Windows Server that doesn’t allow PHP at all. Deploy a virtual machine, and you have full control over that environment.
3. Sandboxes the install. This goes hand in hand with #2, but subtly different. Microsoft’s betas are a good example of the use case for this. Beta software is notorious for being prone to stability issues (it’s beta, go figure). Providing it in a virtual machine allows it to crash and burn without taking out the user’s entire system. The same holds true for the inverse – keeping your application in a virtual machine protects it from another piece of software crashing and burning (of course, if the host system as a whole goes down, that’s a different matter, but other things running on the host machine will have little impact on your software).

Why are you so afraid of letting your customers look at your sourcecode?

• When you are afraid of them stealing your code and reselling it, you can easily protect yourself from that through the license agreement.
• When you are afraid that they might do simple support changes themself and thus cut you out of your consulting and support business, add a clause to the contract that they must not do any modifications themself and when they do they won’t get any more support from you.
• Are you afraid that they might steal your “trade secrets”? When your software is really doing something which is so revolutionary that others can’t replicate it without seeing your sourcecode, patent it. When it isn’t worth patenting, it very likely isn’t worth stealing either.
• Or are you afraid that the quality of your code will not be up to the customers expectations? Improving your code quality should be in your own interest anyway, no matter who sees it.

On the other hand, giving the customer your sourcecode (even when with heavy licensing shackles) also has advantages you can use as a selling point:

• It shows the customer that you trust them
• It shows the customer that they can trust you that there are no hidden backdoors in your software
• It makes it easier for customers to troubleshoot problems themself before contacting you, giving you more meaningful bug reports

For your online customers have you looked at the SAAS model?

This would allow you to host all your web clients on your own servers.

I have experience deploying a similar solution, hosting it in-house and on-premises. For in-house hosting you ofcourse run the code as-is, and for on-premises deployment I’ve used PHP encoder products (ionCube and Zend Guard).

They are both pretty much equivalent. For this product we only switched to Zend Guard because we standardized our on-premises deployment on Zend Server which comes with Zend Guard Loader support out of the box.

Some thoughts on these solutions:

• You have to install the loader extension on the machine where you do hosting, so this may be a dealbreaker for cheap hosting scenarios where you have no control over the server.
• PHP version support always lags behind. Zend Guard just a few weeks ago shipped a version that supports 5.4, and 5.5 is right around the corner.
• There are bugs every now and then specific to the encoded version, especially when using esoteric features (e.g. on PHP 5.2 we couldn’t use reflection to fetch docblock comments in zend guard). It’s not a big deal, but it is something to be aware of.
• There are compatibility issues with some other extensions, notably xdebug. Again, not necessarily a big deal but something to be aware of.
• There is no performance impact that I could tell.
• These solutions have built-in support for licensing using license keys. You should check out the abilities if you’re interested in that sort of stuff.

My company creates a product – a network appliance with PHP software encrypted using SourceGuardian. Our customers aren’t really into hacking, so we’re not worried about them decrypting it. For the average client, this might work out for you – but they need to be using a hosting environment that allows for the source-guardian service to run (or have it already included by the hosting service – many of them support IonCube).

There are many ways to protect your code, although none of them can virtually make you a bullet proof but they do a pretty good job.

In my experience, we develop and distribute several Web Applications written in PHP to end clients, we use the following two products to protect our work:

1. We encrypt our code using the IonCube PHP Encoder – http://www.ioncube.com
2. We use WHMCS’s Licensing Addon – http://www.whmcs.com/addons/licensing-addon

Using the above two products you can do the following

• Protect and license your code before distribution.
• Time restrict your web application to protect evaluation copies
• Protect your scripts against unauthorized use by locking to specific machines
• Restrict access to certain IP, Domain and Directory.

I hope that helps.