Alfresco Content Services 6.0 - now available

Showing results for 
Search instead for 
Did you mean: 

Alfresco Content Services 6.0 - now available

Active Member
8 12 12.4K

The new Alfresco Content Services 6.0 is released, and I am happy to share the highlights of this version with you. The major focus of the new Alfresco Content Services 6.0 release was on significant architecture improvements and the new containerized deployment option based on Docker and Kubernetes.

Containerized deployment

With Alfresco Content Services 6.0, we provide more flexible deployment options including Docker & Kubernetes for fast and standardized deployments across all environments.

For those that prefer the more traditional way of installing Alfresco Content Services or its Community version, we - of course - continue to deliver the WAR files for a manual deployment. But for now, let’s focus on the new containerized deployment with Docker and Kubernetes.


Why have we invested in containerized deployments?

A number of customers and also users in the open source community requested containerized deployment options in the past. The advantages are obvious, it allows development and operations teams to move faster and deploy software in a more efficient way. Containers provide a consistent environment and support DevOps to accelerate development and deployment from the test environment through a staging system to production.  


Do you want to give it a try?

You can test the new improvements around Docker and Kubernetes either with the Community version or start a 30 day free trial of the enterprise version ( ).

Which Alfresco images exist?

The screenshot below shows the currently available Alfresco images that provide:

  • Core parts of Alfresco Content Services like “alfresco-share”, “alfresco-search-services” or the “alfresco-content-repository”
  • Some supporting functionality, e.g. for image or document transformation

How to start with Docker?

With the new release of Alfresco Content Services 6.0, it is now possible to deploy the product from a number of Docker images as described above. But it would be a time-consuming and also complex task to deploy individual Docker containers based on these images. Furthermore, you’d have to do the configuration to make them work together.

Therefore, the recommended way is to use a docker-compose file to get to a “one-click to deploy” experience. A docker-compose file describes the containers of the environment and starts those containers.

This allows you to quickly deploy and run Alfresco Content Services with just a few commands:


$ git clone

$ cd acs-deployment

$ git checkout 1.0.2

$ cd docker-compose

$ docker-compose up


A docker-compose file for testing and development purposes is also available at 

How to start with Kubernetes?

For production environments, we recommend to orchestrate our containers in a kubernetes cluster. It automates tasks like deployment, but also takes care of scaling and managing the containers in the cluster.

Alfresco uses the HELM package manager to provide production-grade reference deployments that can be adopted to your needs. We publish these Charts through our HELM Chart repository.


In many cases, the HELM charts can act as a reference for customized deployments; by basing deployments on the official HELM charts, customers can benefit from the extensive functional and security testing performed by Alfresco (HELM chart releases).


Where to get further information?

Here, you’ll find extensive documentation:


Code Organization

The top-level entry-point for building ACS Enterprise has been moved from Subversion to the Alfresco Content Services Packaging project in GitHub (  Enterprise customers will be able to build the artifacts from scratch provided they have access to the enterprise-releases Nexus repository.

The intention of this restructuring was the following:

  • The code base was split into smaller projects that produce intermediate artifacts with their own versioning
  • The naming of the artifacts changed. The top-level artifacts include the following indicators in their names:
    • "community" to clarify that they are open source
    • "content-services" if they are Enterprise artifacts
    • “-ea” if they are early access versions



This release includes an updated version of the REST API Explorer to navigate the new REST APIs. Those developers that are new to Alfresco should have a closer look at the options the updated REST API provides.

Further information and a full documentation for each endpoint is available at our online REST API Explorer:

Use the userid admin and password admin if you're are using the online REST API explorer. To explore the operations on a specific entity just click on it (“favorites in this case):

If you are using the docker-compose file for development, the api-explorer application will soon be integrated into that.


Anonymous Usage Metrics via Heartbeat

Alfresco Content Services sends anonymous usage metrics to Alfresco through the Heartbeat service. We already used this anonymous information in the past to help understand the usage of our products and to better meet the needs of your organization.

We have been improving the Alfresco Heartbeat to report more detailed information so that we can evolve the product in ways that provide the most value to our customers. As part of this process, we are including the new heartbeat also in the Alfresco Community Edition so that we can better understand how our open source community interacts with the product. This will allow us to better include the needs of both - our customers and our open source community - in our roadmap discussions and decision making process.

Further information around our updated Alfresco Heartbeat is available in our online documentation at

Library Upgrades

With Alfresco Content Services 6.0, we introduced a few library upgrades to ensure ongoing security and to have the ability to leverage more capabilities in future releases. A number of underlying third-party libraries have been updated in both the Repository and Share.

Alfresco Employee

$ git checkout 6.0.0

should be replaced by 

$ cd acs-deployment

$ git checkout 1.0.2

Current GitHub repository does not version ACS release but Helm Charts.

Member II

Awesome announcement.

As part of the core ACS engineering team I really can point out that spinning everything up in a #Docker Environment it speeds up manual and automated #Testing drastically. It feels much more pleasant to work with ACS as it ever did before.

Try it out Smiley Happy !

Alfresco Employee

Hi Angel,

Thanks for the correction Smiley Happy 

For those interested in more details, please also refer to: acs-deployment/ at master · Alfresco/acs-deployment · GitHub 



Active Member

Great catch - just corrected it


The intention of this restructuring was the following:

  • The code base was split into smaller projects that produce intermediate artifacts with their own versioning
  • The naming of the artifacts changed. The top-level artifacts include the following indicators in their names:
    • "community" to clarify that they are open source
    • "content-services" if they are Enterprise artifacts
    • “-ea” if they are early access versions

As already addressed in the latest Office Hours session(s), the change in artifact ID due to product marketing aspects is quite annoying.

The explanation does not appear to be internally consistent. "community" is stated to mark Open Source artifacts, "content-services" Enterprise ones - there is an artifact "org.alfresco:content-services-community" on which based on that explanation would be both open source and enterprise, which seems to be quite a contradiction.

The explanation also appears to be incomplete. Not only is there the "-ea" version suffix, but also a "-ga" one (looking at Only one might have sufficed, i.e. use "-ga" to mark officially supported releases and anything else is EA by default without requiring a suffix.

Confusingly, also contains artifacts where the "-ea" suffix is part of the artifact ID, not the artifact version, which appear to be some early builds from October 2017. Since the explanation only refers to the artifact ID, not the artifact version, this may potentially confuse some people that end up using the wrong (old) artifacts. Are there any plans to clean that up?

While the Alfresco Repository WAR artifact has been renamed to follow the new naming / versioning convention, the Alfresco Share WAR seems to have been left behind using the old conventions (artifact "org.alfresco:share:war:6.0.b" released / deployed to 7 days before the GA release of 6.0). Are there any plans to align the naming / versioning conventions while Share is still officially supported, or do we have to expect Share to keep using the old conventions while we hold vigil at its death bed?

Alfresco Employee

Good point, Axel.
I confirm the discussion into the Office Hours sessions is having a follow-up.

I had the chance to discuss this with Stefan Kopf (from the Repo Team), David Webster and some people in Marketing to keep them aware (especially about the impact of renaming on the developer experience).

As you can imagine it will require time, but I think we are on the right track of the discussion.
More focused comments will be raised here.

Senior Member

Hey Axel, thanks for the feedback. The changes to the way "ACS" is being packaged and versioned come out of the way that the repository has been split up and restructured. The same structural changes were not necessary in the Share project as that already existed as multiple independently versioned projects (Surf, Share, Aikau), so we've not made any changes to the naming or versioning for Share this time around, nor am I aware of any plans to change that.

Similarly with the Records Management module, although there's been a name change to AGS, there's not been the need to restructure that code base and also no need to deviate from the established versioning convention.


For the WAR of the ACS platform I don't yet understand the need for it to have been restructured that way into the acs-packaging project. Similar to how Share is treated in the new packaging project, the Alfresco WAR could have continued to be built from the web-client project (which could well have been split from the other repo projects and renamed, but still kept as the continuation of the WAR build project), and simply be imported into the packaging project as a dependency.

Anyway, what's done is obviously done, or "der Bock ist geschossen". The considerations for a cleaner, more consistent restructuring should have been better reflected upon before the split + move to Git, so more than a year ago. Let's see which - if any - mitigations make sense for the state we have now...

Luckily I have my own parent POM (and am not dependent on SDK) so I can try using profile hacks to deal with this and still maintain simple projects for cross-release builds against any version of 4.2 to 6.0+.

Established Member

When trying to use the api-explorer at 'admin / admin' does not seem to be working as indicated.

Alfresco Employee

Hi Paul,

Every service in the "favourites" group requires a parameter, to work properly. If you don't want to deal with the parameters you can try the audit group, more in particular the GET /audit/applications service.
I hope it helps you.

Established Member

For Enterprise, is it the only way to build your own docker image and deploy or alfresco provide enterprise alfresco content service docker image?


Regardless of Community or Enterprise, you basically always have to build your own Docker images as soon as you want to add customisations / addons. For Enterprise, you'd need access to the private repositories, which you should get via the Support portal.