Not quite in production yet; give me a couple of days. Seriously, I've four sites that should be going beta tomorrow.
It's taken me a while to come up to speed, as my programming background before Lisp was SQL and scripting in shell, perl and PHP. Now that I've made progress up the learning curve, it's an awesome language to work in.
I'm using Hunchentoot, cl-who and CLSQL, with apache in front and PostgreSQL behind. Like Mike, I'm not using the CLOS stuff in CLSQL, and I'm looking at moving to postmodern. Oh, and mel-base is handy for email notifications, plus cl-pdf will be in use for prettier invoices before long. With a bit of refactoring, I've abstracted most of the moving parts into a couple of libraries of my own, and I can now spin off a new site in minutes flat - most of the incremental time for a new site is in the graphic design. Handling multiple domains with a single lisp image isn't a problem; I use apache to manage the domains and SSL termination from the outside, and run a separate hunchentoot server with its own port number and dispatch table for the active portion of each site. Because most of the functionality comes from a common library, adding a site adds very little memory overhead until it starts getting serious traffic. Of course, I say this without having seriously profiled or load-tested them
I looked at EC2, but still have an issue with Amazon's abuse of software patents (one-click checkout is patentable?!), so I'm reluctant to give them money. I've found
http://www.flexiscale.com/, who provide a similar service. This allows me to scale up very quickly if (hopefully when) the sites mature a bit and come to wide public attention. For now, I want them to stay relatively low-profile, because the single worst thing that could happen is that thousands of potential customers visit in the early days, conclude (probably rightly) that it sucks, and never come back. I'm anticipating a lot of refinement right after they go live, and it's easier to do that when you don't have a large userbase to annoy.
The other thing that will help scaling is application architecture: each site shares a base library with the rest, but doesn't share its database or any state. So I can move any given application to a new server, update apache, and instantly handle more load. I haven't yet checked, but it should even be safe to run multiple instances of a given site against a common database server, and load-balance them via apache. The databases all use the same schema, but are separate, so again can be moved to a different database server if contention becomes an issue; this is much less trivial than moving an appserver, proportional to the amount of data that needs moving, but can still be done.
Initially, everything runs on a single server. As traffic ramps up, I'll move the most demanding server (web, app, database) onto its own virtual host. If one of the sites is hogging everything, it'll get its own set of hosts.
A handy hint about using virtual hosting: go for Xen. Virtuozzo doesn't play nice with SBCL; there's a problem with memory allocation. There was when I tried it, anyway. I've no idea about VMware, never having tried it.
Updating an app is relatively easy, with asdf. I use darcs for version control, which is great for producing tarballs of a release and gives me release versioning for free. I combine that with symlinks into asdf's system directory. Unzip a new version, update the new link, fire up a separate lisp image to pre-compile and smoke-test the new version (you never know for sure), then update the running process. To do that, I use screen: reattach to the image actually serving sites, (use-package :cl-user), and use asdf to reload whichever site that needs upgrading. Of course, I haven't tested what happens when you do this while the site's under load, so I may need to stop that application while I upgrade it (10 seconds' worth of interruption).
Disclaimer: I have a few years of experience as a web- and application-server admin in a high-traffic environment, so I learned a few tricks about architecture and version management
Apache is my choice because I've used it for years, I know it well, and I know from experience that it'll handle fairly high loads. I've heard good things about other webserver/proxy software, but will shop around if and when apache starts cracking under the strain of a single site. It's also battle-hardened, so I'm much more comfortable with that exposed to the internet, than I would be by sticking hunchentoot straight out there.
In case you're wondering: yes, there's an excellent chance that I'll release and open-source the libraries if it looks like a worthwhile contribution. However, they need a lot of refinement before I can do that with a straight face.