Blog Article

Droplet Computing launches DCA v1.2 with new features designed for the enterprise

Droplet Computing launches DCA v1.2 with new features designed for the enterprise

Date: 6 December 2019 | By: admin

Software development never seems to sit still for very long. It only seems like it was yesterday that I wrote about launching v1.1 of Droplet Container App (DCA) and all the features that were included in that version.
Here at Droplet Computing we take our customer and partner feedback seriously and look to develop new features in each new version with features designed to tackle real-life customer issues. So, it’s no surprise that in this latest v1.2 release we have listened carefully to how we can deliver a solution that helps our customers deliver their apps within their existing environments and existing infrastructure. To that end, we are today excited to announce the release of DCA v1.2!

So, let’s dive into these new features and how they help redefine app delivery for the enterprise.


With the DirectLaunch feature, you can start guest apps within the container image directly from the host using a command-line switch. For example, typing droplet.exe launch calc.exe will start the container as usual and will automatically launch calculator once the container is full loaded. If the container is already up and running, then calculator will launch immediately.

Why have we added the DirectLaunch feature?

The answer is so that we have a greater level of integration into Amazon WorkSpaces and AppStream, as well as Citrix Virtual Apps and VMware Horizon Apps.The app icon appears as it would normally within these solutions for the end user to launch.

You can read our Citrix Virtual Apps & Desktops integration guide by clicking here.

Typically, the end user would launch their Droplet Computing containerised app from the Droplet Workspace interface, however, these other solutions already have a portal-style interface so it makes sense when using these solutions not to double-up and therefore make the end user experience simpler and slicker when launching apps.

Look out for further development of the DirectLaunch feature, including adding the ability to automate the creation of the app links/paths.

Example configuration for DirectLaunch from the desktop

Extended Linux host support
In v1.2 we have added support for running the Droplet Container Image (DCI) on 64-bit Linux machines. This, depending on the container image used, will support both accelerated (using Intel HAXM) and non-accelerated hardware.

We are starting to see a greater demand for Linux-based endpoints and Linux-based virtual desktop machines, both running on premises and as DaaS solutions, such as Amazon WorkSpaces. Adding extended support for Linux to DCA enables a greater range of apps to run inside the container that may require more resources in order to run on a Linux host. This also leads us to the next addition, adding more resource to the container.

Increased container memory resources

Memory can be configured in steps, selecting either 1GB, 2GB, 4GB, or now 8GB ensuring you can allocate the appropriate amount of memory for the apps inside the container to address.

Mass deployment for the enterprise
Probably one of the most asked questions around deploying Droplet Computing containers and container image files is how to handle mass deployment in an enterprise environment.

The next most asked question is should you have one container image per app, or install all your apps in one container image? Rather than giving the usual “it depends” answer, with this new feature we can answer this more definitively. The only caveat being that if you need to isolate apps from each other due to software conflicts such as different Java versions for example, then one container image per app is the way to go. That’s also the way if you want to run different container image types too.

So, how does Droplet Computing handle mass deployment when potentially different users or groups of users require different apps?

When you build a container image you are building the gold master image that is deployed to all users, so therefore you can install all your apps into the container and then with the new Export apps.json feature (available in container admin mode when the container is unlocked), you can export a simple .json file that contains the configuration of the Droplet Workspace interface that contains the app tiles or icons for those apps you have selected.

To export the app.json file, simply click the Export apps.json button while the container is unlocked and in admin mode.

Now you have several different configuration files. For example, one for sales, one for marketing, and one for finance. What do you do with them now? Quite simply you deploy them via your directory service. For example, when an end user logs in to Active Directory, they will pick up their user settings from their profile via group policy. One of these settings is the apps.json file relevant to their role. So, if they are in the sales AD group, they receive the apps.json file for sales that contains the details of the sales apps. Then, when they launch their container, only those apps will be available for them to launch.

If the end user moves department then it’s a simple case of them being moved from one AD group to another and picking up the new apps.json file and, hey presto, they see a different set of apps in their Droplet Workspace. It’s akin to the app cloaking or app masking feature you would see in something like an app layering solution. Either way, it simplifies the deployment and app accessibility.

Additional end user security features
One of the features built into the current DCA is the ability to open an explorer style window within the container, or on the host device. This explorer window displays the folder that is shared between the two. It can be used to install smaller apps instead of using a network drive.

To make this feature more secure, we have essentially added an on and off button, configurable when the container is unlocked and in admin mode.

By disabling the file share means that end users cannot browse the files inside the container and therefore it removes the potential for them to create or delete files. This adds an extra level of security and protection to the container image. The container image itself remains persistent so anything an end users saves inside the container remains there even after powering the container off.

To configure file sharing, simply click the switch for Enabled or Disabled while the container is unlocked and in admin mode.

As with the apps.json file that stores app configuration information, there is also a settings.json file that stores the settings of the container app. This file can also be deployed via group policy in the use case that different users may need access and others don’t. Perhaps we will add a button for that too?!

In summary
As you can see, we have added several new features aimed at making the deployment of DCA much easier when it comes to enterprise deployments. These new features also include some added security and lock-down options, as well as adding support for more host operating systems and the ability to add additional resources to take full advantage of these more advanced OS’s.

We may well be heading into the holiday season, but there is no rest for us at Droplet Computing. We are already busy with the beta of v1.3 that includes some really cool features.