Bitbucket DC should offer a persistent JVM configuration, that would survive the subsequent upgrades of Bitbucket DC.

Currently, the most common approach is to edit $BITBUCKET_INSTALL_DIR/bin/_start-webapp.sh where specific JVM arguments can be added. However:

• It is risky. These script customisations will be lost as soon as Bitbucket DC is upgraded. The new Product version will be installed in a new folder, where a fresh copy of _start-webapp.sh will be created and used.
  You will need to remember to re-customise this script after each upgrade, which is error prone.
  If you forget, upgraded Bitbucket DC will be started with default JVM configuration, including -Xms512m -Xmx1g which is too low for most large deployments, risking an outage due to the java.lang.OutOfMemoryError
• Modifying Bitbucket's startup scripts is generally not the best practice.
  It would have been better to keep these customisations in a separate configuration file, that Bitbucket's scripts could reference, and where the custom JVM arguments would not be wiped off by the next upgrade.

Bitbucket DC should offer an easy way to configure persistent custom JVM arguments.

• Some of these JVM arguments may need to be applied across the entire DC cluster, eg.

  -Xms... -Xmx...
  -Dhttp.proxyHost=... -Dhttps.proxyHost=...
  -Dhttp.proxyPort=... -Dhttps.proxyPort=...
  -Dhttp.nonProxyHosts=...
  

  etc.

• Other custom JVM arguments may have to be node-specific, eg.

  -Dcluster.node.name=...
  

Workaround

Use specific environment variables to define custom JVM arguments, eg.

export JVM_MAXIMUM_MEMORY=2g
export JVM_MINIMUM_MEMORY=2g

will ensure that Bitbucket's JVM is created with -Xms2g -Xmx2g.
However, these environment variables must be applied for the Linux user Bitbucket runs as (eg. atlbitbucket) before the JVM is created, which is not trivial to ensure.