What approach should I use to enable a customer to deploy content (just items) from their CM environment to a CD environment, where the CD environment would not allow any SQL ports through the firewall? Something like zipping up a package or serialization files, uploading that over HTTP, unpacking and installing it, and then clearing caches? It would be even better if this could be a single SQL transaction. Has anyone ever done anything like this? Maybe I'm missing something obvious. Could TDS, Sitecore Ship, Unicorn, SSC, or anything else assist here?

Because the customer might want to use the publishing service (https://dev.sitecore.net/Downloads/Sitecore_Publishing_Service.aspx) after they get to 8.2, any solution probably not depend on publishing pipelines. I'm not familiar enough with any of these technologies to make a recommendation.

Feel free to tell me to RSomeFM or blog posts or something. I would be happy to do some development; mostly looking for architectural and toolset suggestions.

  • 2
    First thought is Sitecore PowerShell as you could create a package programmatically given a context node, which is pretty close to the publish model. Then ship the package (ftp/rest?), and install on the other side, again with PSE. The 'install' events can be used for cache clearing just like publish:end:remote... But you already knew that ;) Commented Sep 19, 2016 at 2:48
  • 1
    FWIW, a single IP SQL Port (IPSec) should not be considered a security risk. This can't be spoofed in a useful way without forward knowledge of the gateway IP of the AUTH environment, which would likely be impossible. Commented Sep 19, 2016 at 10:33
  • 1
    The publishing service has direct connections to the SQL Server, so that is going to need access via the SQL Ports. Seems like a very OTT security requirement to me.
    – Richard Seal
    Commented Sep 19, 2016 at 13:14
  • IIRC, Sitecore 5.0 had a webservice based publish engine specifically for this reason. Commented Oct 26, 2016 at 18:19

5 Answers 5


Ok. Well. Would definitely be possible to set something up with Unicorn for this - albeit it a highly unusual configuration. Steps I would take would look something like this:

  • Set up Unicorn on the CM box to serialize all of the web content you want to regularly push across to CD
  • This will ensure, the file system always has a copy of everything that is being published on CM
  • I would then use the same config on CD

Then, come time to publish:

Script a "publish". Since I'm no good with SPE, I would probably use gulp. Steps would or could be something like:

  • Zip up the Unicorn folder
  • FTP upload it (or any other means of transfer) to CD server
  • Delete CD servers Unicorn/** folder
  • Unzip uploaded file to CD servers Unicorn folder
  • Run Unicorn sync via its remote script capability

Rough outline at least. There could be any number of unforeseen consequences of this setup I'm not seeing right now; I've never attempted to set anything up like this.

Also; having all of these tools available on CD (Unicorn, Remote Scripting) might actually be a bigger security risk than a 1 way port SQL opening - but that's just my opinion of course.

  • Combine this with some sort of cloud repo for the Unicorn package, and a cloud message queue to trigger the import, and you wouldn't need remote scripting right? Commented Sep 19, 2016 at 15:36
  • Very likely. I am a cloud n00b ;-)
    – Mark Cassidy
    Commented Sep 19, 2016 at 15:37

You might take a look at the new Vault product from XCentium. They do some really interesting things with moving content between environments using Git. Not sure whether your network restrictions would be prohibitive but might be an option.


Creating a secure VPN to the CD environment, possibly temporarily for the publish operation would seem like a straightforward way of fulfilling the brief without engineering something new.

Obviously this just swaps a firewall rule for SQL to a firewall rule for VPN, but it's not clear from the question why such restrictions exist.


I can only speak to the Publishing Service but it was designed with some of these considerations in mind (although this would require quite a bit of customization as it currently stands!)

When the publish starts its builds what is called a manifest. This contains all the items that are to be created/updated/deleted for a certain publish. You could use the information in the manifest to construct a package of these items and then ship this across to your CD environment.

This is the more extreme case, maybe a simpler one would be to move the publishing service onto the same machine as the sql db (it is very small!). Then all commands are issued from Sitecore via HTTP (if that is better than SQL ports being opened) and all SQL work is done using local connections (with nothing flowing across the network).


About a decade ago, I believe Sitecore's publishing strategies included a web service based scenario, where the Authoring server would talk to the Delivery server via web services, transferring Items that way.

Rather than mess with extremely finicky file system strategies, I'd strongly consider using the new Restful APIs to achieve something similar.

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.