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

At present, there is no known way to configure custom JVM arguments that would not be removed by the next Bitbucket upgrade.
The only workaround is to re-apply these custom JVM arguments after every upgrade.