Have a question? Want to report an issue? Contact JFrog support

Skip to end of metadata
Go to start of metadata


This page presents release notes for JFrog Mission Control describing the main fixes and enhancements made to each version as it is released.


Click to download the latest version of  JFrog Mission Control.


For installation instructions please refer to Installing Mission Control

To upgrade to the latest version, please refer to Upgrading Mission Control

(lightbulb) To receive automatic notifications whenever there is a new release of Mission Control, please watch us on Bintray.

Mission Control 2.1

January 8, 2018

Ubuntu and Red Hat Installation 

This release introduces support for additional flavors of Linux and adds Ubuntu 16.x and and Red Hat 7.x as supported platforms. For details on how to install Mission Control on these platforms, please refer to Installing Mission Control. . 

Using External Databases

Mission Control uses Elasticsearch, MongoDB and PostgreSQL databases for its different functions, and until now, would install dedicated instances of each of these databases. This version gives you more control of your resources and lets you direct Mission Control to use instances of these databases you may already have installed and in use, rather than creating new ones. Offering full flexibility, during the installation or upgrade process, Mission Control lets you select which databases should externalized and which Mission Control should create for its own dedicated use.

Maven Metadata in DR Repositories Tab 

In addition to the replication status, for Maven packages, the DR Repositories tab now also includes the metadata file count and size for each repository.

System Monitoring

Mission Control now displays your general system status as an icon on the top ribbon of the UI. Services notifications are automatically updated at all times. 

Feature Enhancements
  1. In both the UI and the REST API, the option to execute a script on a non-online service is blocked. 
  2. JFrog Mission Control blocks creating a DR pair when the master version is higher than target version. 
  3. In the REST API, two new commands have been added. The Change Password command allows users to change their own password and enables the admin to change passwords for all users. The Partial Update Site By Name command updates site information without updating the attributes.
  4. When setting DR, you can manually set the replication socket timeout in the DR configuration properties file.
  5. Mission Control allows you to add a commit message when updating a script.
  6. The Top 5 Services graph now displays the percentage of used storage. 


Page Contents

Mission Control 2.1.1

January 23, 2018

Helm Chart Repositories

This release adds full support in Mission Control for Helm Chart repositories which were introduced in JFrog Artifactory 5.8. 

Mission Control 2.0

November 20, 2017

JFrog is pleased to release Mission Control 2.0.

This release introduces many changes from version 1.x to improve workflow and efficiency in managing your global Artifactory and Xray services. Yes, you read correctly, Mission Control now also manages your Xray services. In addition, Mission Control 2.0 introduces significant changes in installation and upgrade procedure, workflow for adding and managing services, a new concept of Sites that associate services to a geographic location, improvements in Usage Graphs and more. 

Note that some of the new features and enhancements are breaking changes that are not compatible with version 1.x. In these cases, we offer a migration path to version 2.0. 

For details about the changes introduced by Mission Control 2.0, please read the sections below.


Artifactory and Xray Services

In addition to managing your Enterprise Artifactory instances, Mission Control can now also manage the JFrog Xray instances attached to them. This allows you to do things like configure connections between Artifactory and Xray services, use scripts to create Watches and more.  

To manage Artifactory or Xray instances through Mission Control, they must be added as Services and be assigned to Sites.


Scripting has undergone significant changes in Mission Control 2.0. Most importantly, configuration scripts are now much more flexible allowing you to operate on as many Artifactory or Xray services, and on any number of repositories as you want in a single script (previously, each script could only perform one action on a single service). To support this capability, Mission Control 2.0 introduces service closures in configuration scripts. These define the Artifactory and Xray instances on which the script operates and enclose the different configuration blocks that create or implement changes on Artifactory and Xray services.

The scripting DSL has also been significantly enhanced with new configuration blocks. These include configuration blocks to create and configure Xray services, a security block to configure users, groups and permissions in Artifactory services and more. Make sure to check out the Star Topology configuration blocks that make it very easy to set up a complex one-to-many replication relationship using three lines of code. Not also that applying a Star Topology configuration to all members of a star actually implements a full mesh topology.

Breaking Change - You need to migrate your scripts

The new scripting mechanism is a breaking change which means that scripts written for JFrog Mission Control 1.x will not work in version 2.0 and above. While there is no way to migrate your scripts automatically, the process is not very complicated. For guidelines and best practices for migrating your scripts please refer to Migrating Scripts from Version 1.x to Version 2.x.


The Graphs UI has been enhanced to give you an easy way to focus on different Artifactory instances and repositories and also zoom in on specific time periods on historical usage graphs. From version 2.0, Mission Control uses a new Elasticsearch database to store historical usage data. Upon installation of the new version, the previous InfluxDB database will no longer be used, and usage data will only be collected in the new database. 

[Optional] You may migrate historical usage data from InfluxDB to Elastic Search

If you wish to continue viewing historical usage data collected in the InfluxDB database of versions 1.x, you can migrate this data to the new Elasticsearch database using the process described in Migrating Scripts from Version 1.x to Version 2.x.

Installation and Upgrade

Instructions for installing and upgrading to version 2.0 have changed, but remain simple procedures, with support for CentOS, Debian and Docker installations. 

To install Mission Control 2.0 as CentOS or Debian distribution, please refer to Installing Mission Control

To install and run the Mission Control Docker image, please refer to Running with Docker

ZIP installation is deprecated

From version 2.0, Mission Control is no longer available as a ZIP installation.


Mission Control 2.0 introduces a completely new REST API that accommodates all the new functionality introduced in this version. The new REST API adds several new endpoints, but also removes some, including endpoints related to configuring users, groups and permissions in Artifactory since this functionality is now available through JFMC scripting. From Mission Control 2.0, the REST API v3 is active, while the REST API v2 is deprecated. 

Breaking Change - You need to migrate your REST API calls

The new REST API is a breaking change which means any scripts that use the previous REST API version will not work. To learn how to migrate your scripts to the new REST API, please refer to Version Mappings in the new Mission Control REST API page.


Sites are a new concept in JFrog Mission Control. They represent physical locations (cities) into which you can aggregate the different Artifactory and Xray services serving them. Any service defined in Mission Control must be assigned to a site. Sites are displayed in the Explore module (which replaces the old Dashboard module) and can display sites as a list view or on a map. 

Existing Artifactory services are automatically assigned to a site

When you upgrade to Mission Control 2.0, any Artifactory services already managed by your current version of Mission Control will be assigned to new Sites that will be created according to the location of your Artifactory instances. For example, an Artifactory service located in San Fransisco, will be assigned to a new site in Mission Control that's located in San Fransisco.

Artifactory services that do not have a location will be placed in the "Unassigned Services" site by default.

"Groups" feature is deprecated

From version 2.0, collecting managed Artifactory services into "Groups" is deprecated. All services should be placed in the context of a Site.

Feature Enhancements

  1. Mission Control startup time has been greatly improved.
  2. Mission Control's DSL has been enhanced with new configuration blocks to allow extremely easy configuration of replication relationships that implement Star Topologies for geographically distant Artifactory services. starPush configures a multi-push replication relationship while starPull configures pull replication. As a result, the multipushReplication configuration block, which is now redundant, has been deprecated. 
  3. The Execute Script REST API endpoint has been enhanced to provide more detailed error messages if script execution fails

Issues Resolved

  1. Fixed an issue that prevented Mission Control from implementing DR when the Master Artifactory instance was using encrypted passwords.