Bitbucket Server config properties

This page describes the Bitbucket Server system properties that can be used to control aspects of the behavior in Bitbucket Server. Create the bitbucket.properties file, in the shared folder of your Bitbucket Server home directory, and add the system properties you need, use the standard format for Java properties files.

Note that the bitbucket.properties file is created automatically when you perform a database migration.

Bitbucket Server must be restarted for changes to become effective.

Default values for system properties, where applicable, are specified in the tables below.

On this page:

 

 

Audit

Property Description
audit.highest.priority.to.log=HIGH

Defines the lowest priority audit events that will be logged.
Accepted values are: HIGH, MEDIUM, LOW and NONE.

Setting the value to HIGH will result in only HIGH level events being logged. NONE will cause no events to be logged. MEDIUM will only allow events with a priority of MEDIUM and HIGH to be logged.

Refer to the levels for the various events.

This does not affect events displayed in the Audit log screens for projects and repositories.

audit.details.max.length=1024
Defines the number of characters that can be can stored as details for a single audit entry.
plugin.bitbucket-audit.max.entity.rows=500

The maximum number of entries a project or repository can have in the audit tables.

This does not affect the data stored in the logs.

plugin.bitbucket-audit.cleanup.batch.size=1000

When trimming the audit entries table this is the maximum number of rows that will be trimmed in one transaction. Reduce this size if you are having issues with long running transactions.

This does not affect the data stored in the logs.

plugin.bitbucket-audit.cleanup.run.interval=24

How often the audit tables will be checked to see if they need to be trimmed (in hours).

This does not affect the data stored in the logs.

Authentication

See also Connecting Bitbucket Server to Crowd.

Property Description
plugin.auth-crowd.sso.enabled=false Whether SSO support should be enabled or not. Regardless of this setting SSO authentication will only be activated when a Crowd directory is configured in Bitbucket Server that is configured for SSO.
plugin.auth-crowd.sso.session.lastvalidation=atl.crowd.sso.lastvalidation The session key to use when storing a Date value of the user's last authentication.
plugin.auth-crowd.sso.session.tokenkey=atl.crowd.sso.tokenkey The session key to use when storing a String value of the user's authentication token.
plugin.auth-crowd.sso.session.validationinterval=3
The number of minutes to cache authentication validation in the session. If this value is set to 0, the SSO session will be validated with the Crowd server for every HTTP request.
plugin.auth-crowd.sso.http.max.connections=20
The maximum number of HTTP connections in the connection pool for communication with the Crowd server.
plugin.auth-crowd.sso.http.proxy.host
The name of the proxy server used to transport SOAP traffic to the Crowd server.
plugin.auth-crowd.sso.http.proxy.port
The connection port of the proxy server (must be specified if a proxy host is specified).
plugin.auth-crowd.sso.http.proxy.username
The username used to authenticate with the proxy server (if the proxy server requires authentication).
plugin.auth-crowd.sso.http.proxy.password
The password used to authenticate with the proxy server (if the proxy server requires authentication).
plugin.auth-crowd.sso.http.timeout=5000
The HTTP connection timeout in milliseconds used for communication with the Crowd server. A value of zero indicates that there is no connection timeout.
plugin.auth-crowd.sso.socket.timeout=20000
The socket timeout in milliseconds. You may wish to override the default value if the latency to the Crowd server is high.
auth.remember-me.enabled=optional

Controls whether remember-me authentication is disabled, always performed or only performed when a checkbox is checked on the login form. The 'Remember my login' checkbox is only displayed when set to 'optional'.
Possible values are:

  • always: no checkbox, remember-me cookie is always generated on successful login.
  • optional: checkbox is displayed on login form. Remember-me cookie is only generated when checkbox is checked.
  • never: Remember-me authentication is disabled completely.
auth.remember-me.token.expiry=30

How long remember-me tokens are valid. Note that once a remember-me token is used for authentication, the token is invalidated and a new remember-me token is returned.

Value is in DAYS.

Avatars

Property Description
avatar.gravatar.default=mm

The fallback URL for Gravatar avatars when a user does not have an acceptable avatar configured. This may be a URL resource, or a Gravatar provided default set. 

This configuration setting is DEPRECATED. It will be removed in Bitbucket Server 3.0. Use avatar.url.default instead.

avatar.max.dimension=1024

Controls the max height and width for an avatar image. Even if the avatar is within the acceptable file size, if its dimensions exceed this value for height or width, it will be rejected. 

When an avatar is loaded by the server for processing, images with large dimensions may expand from as small as a few kilobytes on disk to consume a substantially larger amount of memory, depending on how well the image data was compressed. Increasing this limit can substantially increase the amount of heap used while processing avatars and may result in OutOfMemoryErrors. 

Value is in PIXELS.

avatar.max.size=1048576

Controls how large an avatar is allowed to be. Avatars larger than this are rejected and cannot be uploaded to the server, to prevent excessive disk usage. 

Value is in BYTES.

avatar.temporary.cleanup.interval=1800000

Controls how frequently temporary avatars are cleaned up. Any temporary avatars that have been uploaded are checked against their configured max age and removed from the file system if they are "too old". 

Value is in MILLISECONDS.

avatar.temporary.max.age=30

Controls how long a temporary avatar that has been uploaded is retained before it is automatically deleted. 

Value is in MINUTES.

avatar.url.default=${avatar.gravatar.default} Defines the fallback URL to be formatted into the avatar.url.format.http or avatar.url.format.https URL format for use when a user does not have an acceptable avatar configured. This value may be a URL or, if using Gravatar, it may be the identifier for one of Gravatar's default avatars. 

The default here falls back on the now-deprecated avatar.gravatar.default setting, which should ensure that value, if set, continues to work until it is removed in Bitbucket Server 3.0. At that time, this default will become "mm".

avatar.url.format.http=http://www.gravatar.com/
avatar/%1$s.jpg?s=%2$d&d=%3$s

Defines the default URL format for retrieving user avatars over HTTP. This default uses any G-rated avatar provided by the Gravatar service [http://www.gravatar.com

The following format parameters are available: 
%1$s – the user's e-mail address, MD5 hashed, or "00000000000000000000000000000000" if the user has no e-mail.
%2$d – the requested avatar size.
%3$s – the fallback URL, URL-encoded, which may be defined using "avatar.url.default".
%4$s – the user's e-mail address, not hashed, or an empty string if the user has no e-mail.

avatar.url.format.https=https://secure.gravatar.com/
avatar/%1$s.jpg?s=%2$d&d=%3$s

Defines the default URL format for retrieving user avatars over HTTPS. This default uses any G-rated avatar provided by the Gravatar service [http://www.gravatar.com

The following format parameters are available: 
%1$s – the user's e-mail address, MD5 hashed, or "00000000000000000000000000000000" if the user has no e-mail.
%2$d – the requested avatar size.
%3$s – the fallback URL, URL-encoded, which may be defined using "avatar.url.default".
%4$s – the user's e-mail address, not hashed, or an empty string if the user has no e-mail.

Backup

Property Description
backup.drain.database.timeout=60

Defines the number of seconds Bitbucket Server will wait for connections to the database to drain and latch in preparation for a backup.

Value is in SECONDS.

backup.scmdrain.timeout=60

Defines the number of seconds Bitbucket Server will wait for in-progress git operations to drain in preparation for a backup.

Value is in SECONDS.

 

Changesets

 

Property Description
changeset.diff.context=10 Defines the number of context lines to include around diff segments in changeset diffs.

 

Changeset indexing

These properties control how changesets are indexed when new commits are pushed to Bitbucket Server.

Property Description
indexing.max.threads=2

Controls the maximum number of threads which are used to perform indexing. The resource limits configured below are not applied to these threads, so using a high number may negatively impact server performance.

indexing.job.batch.size=250 Defines the number of changesets which will be indexed in a single database transaction.
indexing.job.queue.size=150 Defines the maximum number of pending indexing requests. When this limit is reached, attempts to queue another indexing operation will be rejected.
indexing.process.timeout.execution=3600

Controls how long indexing processes are allowed to execute before they are interrupted, even if they are producing output or consuming input. 

Value is in SECONDS.

 

Commit graph cache

Property Description
commit.graph.cache.min.free.space=1073741824

Controls how much space needs to be available on disk (specifically under <Bitbucket home directory>/caches) for caching to be enabled. This setting ensures that the cache plugin does not fill up the disk.

Value is in BYTES.

commit.graph.cache.max.threads=2 Defines the number of threads that will be used to create commit graph cache entries.
commit.graph.cache.max.job.queue=1000 Defines the maximum number of pending cache creation jobs.

 

Database

Database properties allow very specific configuration for your database connection parameters, which are set by Bitbucket Server during database setup and migration, and allow you to configure a database of your own. We don't expect that you will edit these, except in collaboration with Atlassian Support.

If none of the properties below are specified in bitbucket.properties, then the internal HSQL database will be used.

If the jdbc.driver, jdbc.url, jdbc.password and jdbc.user properties are specified in bitbucket.properties when the Setup Wizard runs after installing Bitbucket Server, then those values will be used, and the Setup Wizard will not display the database configuration screen.

Any other driver must be placed in WEB-INF/lib in order to use the associated database. 

(warning) Warning: jdbc.driver and jdbc.url are available to plugins via the ApplicationPropertiesService. Some JDBC drivers allow the username and password to be defined in the URL. Because that property is available throughout the system (and will be included in STP support requests), that approach should not be used. The jdbc.username and jdbc.password properties should be used for these values instead.

Property Description
jdbc.driver=org.hsqldb.jdbcDriver

The JDBC driver class that should be used by Bitbucket Server to connect to the database.

The internal Bitbucket Server database is HSQL and uses org.hsqldb.jdbcDriver. It stores its data in the Bitbucket Server home directory

Bitbucket Server bundles these other JDBC drivers:

  • org.postgresql.Driver (more info)

  • com.microsoft.sqlserver.jdbc.SQLServerDriver (more info)

  • oracle.jdbc.driver.OracleDriver (more info)

The JDBC drivers for MySQL are not  bundled with Bitbucket Server (due to licensing restrictions) so you will need to download and install the driver yourself. See Connecting Bitbucket Server to MySQL for instructions.

jdbc.url=jdbc:hsqldb:${bitbucket.home}/data/db;shutdown=true This is the JDBC url that Bitbucket Server will use to connect to the database. This should include the driver subprotocol (e.g., postgresql:), the hostname, port and database that you will connect to. This string may vary depending on the database you are connecting to. Please seek specific examples for other databases from your database provider.
jdbc.user=bitbucket This is the user that Bitbucket Server will connect to the database with. The user will need to be able to create and drop tables and indexes, as well as read and write operations on the entire database schema defined in jdbc.url.
jdbc.password=bitbucket The password that the user defined by jdbc.user will connect with.
jdbc.ignoreunsupported=false Allows using a given database, even though it is marked as UNSUPPORTED. This is not intended to be broadly documented, nor to be used generally. It is here as a support mechanism to override the supported database check in the event that it incorrectly blocks access to a database.

 

Database pool

These properties control the database pool. The pool implementation used is HikariCP. Documentation for these settings can be found at: https://github.com/brettwooldridge/HikariCP/wiki/Configuration 

To get a feel for how these settings really work in practice, the most relevant classes in HikariCP are:

  • com.zaxxer.hikari.HikariConfig Holds the configuration for the database pool and has documentation for the available settings.
  • com.zaxxer.hikari.pool.HikariPool Provides the database pool and manages connections.
  • com.zaxxer.hikari.util.ConnectionBag Holds references to open connections, whether in-use or idle.
Property Description
db.pool.size.idle=0

Defines the number of connections the pool tries to keep idle. The system can have more idle connections than the value configured here. As connections are borrowed from the pool, this value is used to control whether the pool will eagerly open new connections to try and keep some number idle, which can help smooth ramp-up for load spikes.
By default, the system does not eagerly open new idle connections. Connections will be opened as needed.

Once opened, connections may become idle and will be retained for db.pool.timeout.idle seconds.

db.pool.size.max=80

Defines the maximum number of connections the pool can have open at once.

db.pool.timeout.connect=15

Defines the amount of time the system will wait when attempting to open a new connection before throwing an exception.
The system may hang, during startup, for the configured number of seconds if the database is unavailable. As a result, the timeout configured here should not be generous.

This value is in SECONDS.

db.pool.timeout.idle=1750

Defines the maximum period of time a connection may be idle before it is closed. In general, generous values should be used here to prevent creating and destroying many short-lived database connections (which defeats the purpose of pooling).

Note: If an aggressive timeout is configured on the database server, a more aggressive timeout must be used here to avoid issues caused by the database server closing connections from its end. The value applied here should ensure the system closes idle connections before the database server does. This value needs to be less than db.pool.timeout.lifetime otherwise the idle timeout will be ignored.

This value is in SECONDS.

db.pool.timeout.leak=0

Defines the maximum period of time a connection may be checked out before it is reported as a potential leak. By default, leak detection is not enabled. Long-running tasks, such as taking a backup or migrating databases, can easily exceed this threshold and trigger a false positive detection.

This value is in MINUTES.

db.pool.timeout.lifetime=30

Defines the maximum lifetime for a connection. Connections which exceed this threshold are closed the first time they become idle and fresh connections are opened.

This value is in MINUTES.

 

Display

Property Description
display.max.source.lines=20000 Controls how many lines of a source file will be retrieved before a warning banner is shown that encourages the user is to download the raw file for further inspection. This property relates to page.max.source.lines (see Paging below) in that up to (display.max.source.lines / page.max.source.lines) requests will be made to view the page.

 

Downloads

Property Description
http.download.raw.policy=Smart

Controls the download policy for raw content.

Possible values are: 
Insecure – allows all file types to be viewed in the browser.
Secure – requires all file types to be downloaded rather than viewed in the browser.
Smart – forces "dangerous" file types to be downloaded, rather than allowing them to be viewed in the browser.
These options are case-sensitive and defined in com.atlassian.http.mime.DownloadPolicy.

Elasticsearch

Bitbucket Server 4.6+ ships with an embedded instance of Elasticsearch. These properties enable admins to configure the base URL of the Elasticsearch instance, and enable basic security measures in the form of a username and password for accessing the Elasticsearch instance. 

If an Elasticsearch parameter is set in the properties file, it cannot be edited later from the admin UI. Any changes that need to be made to the Elasticsearch configuration must be made within the bitbucket.properties file.

Property
Description
plugin.search.elasticsearch.baseurl
Sets the base URL of an Elasticsearch instance.
plugin.search.elasticsearch.username
Username for connecting to an Elasticsearch instance.
plugin.search.elasticsearch.password
Password for connecting to an Elasticsearch instance.
plugin.search.elasticsearch.aws.region
AWS region Bitbucket is running in. When set, enables request signing for Amazon Elasticsearch Service.

Events

These properties control the number of threads that are used for dispatching asynchronous events. Setting this number too high can decrease overall throughput when the system is under high load because of the additional overhead of context switching. Configuring too few threads for event dispatching can lead to events being queued up, thereby reducing throughput. These defaults scale the number of dispatcher threads with the number of available CPU cores.

Property Description
event.dispatcher.core.threads=0.8*${scaling.concurrency}
The minimum number of threads that is available to the event dispatcher. The ${scaling.concurrency} variable is resolved to the number of CPUs that are available.
event.dispatcher.max.threads=${scaling.concurrency}
The maximum number of event dispatcher threads. The number of dispatcher threads will only be increased when the event queue is full and max.threads has not been reached yet.
event.dispatcher.queue.size=4096 The number of events that can be queued. When the queue is full and no more threads can be created to handle the events, events will be discarded.
event.dispatcher.keepAlive=60

The time a dispatcher thread will be kept alive when the queue is empty and more than core.threads threads are running. 

Value is in SECONDS.

 

Executor

Controls the thread pool that is made available to plugins for asynchronous processing.

Property Description
executor.max.threads=${scaling.concurrency}

Specifies the maximum number of threads in the thread pool. When more threads are required than the configured maximum, the thread attempting to schedule an asynchronous task to be executed will block until a thread in the pool becomes available.

The ${scaling.concurrency}  
variable is resolved to the number of CPUs that are available.

 

Features

Feature properties control high-level system features, allowing them to be disabled for the entire instance. Features  that are disabled at this level are disabled completely. This means that instance-level configuration for a feature is overridden. It also means that a user's permissions are irrelevant; a feature is still disabled even if the user has the SYS_ADMIN permission.

Property Description
attachment.upload.max.size=10485760

Controls the file size limit for individual attachments to pull request comments and descriptions.

Value is in bytes.

feature.attachments=true Controls whether attachments can be added to pull request comments and descriptions.
feature.auth.captcha=true

Controls whether to require CAPTCHA verification when the number of failed logins is exceeded. If enabled, any client who has exceeded the number of failed logins allowed using either the Bitbucket Server web interface or the Git hosting interface will be required to authenticate in the Bitbucket Server web interface and successfully submit a CAPTCHA before continuing. Setting this to false will remove this restriction and allow users to incorrectly authenticate as many times as they like without penalty.

(warning) Warning: It is STRONGLY recommended you keep this setting enabled. Disabling it will have the following ramifications:

  • Your users may lock themselves out of any underlying user directory service (LDAP, Active Directory etc) because Bitbucket Server will pass through all authentication requests (regardless of the number of previous failures) to the underlying directory service.
  • For Bitbucket Server installations where you use Bitbucket Server for user management or where you use a directory service with no limit on the number of failed logins before locking out users, you will open Bitbucket Server or the directory service up to brute-force password attacks.
feature.forks=true Controls whether repositories can be forked. This setting supersedes and overrides instance-level configuration.
If this is set to false, even repositories which are marked as forkable cannot be forked.
feature.personal.repos=true

Controls whether personal repositories can be created.

When set to false, personal repository creation is disabled globally in Bitbucket Server.

feature.public.access=true Public access to Bitbucket Server allows unauthenticated users to be granted access to projects and repositories for specific read operations including cloning and browsing repositories. This is normally controlled by project and repository administrators but can be switched off system wide by setting this property to false. This can be useful in highly sensitive environments.

 

Hibernate

Property

Description

hibernate.format_sql=false 

When hibernate.show_sql is enabled, this flag controls whether Hibernate will format the output SQL to make it easier to read.

hibernate.jdbc.batch_size=20

Controls Hibernate's JDBC batching limit, which is used to make bulk processing more efficient (both for processing and for memory usage).

hibernate.show_sql=false

Used to enable Hibernate SQL logging, which may be useful in debugging database issues. This value should generally only be set by developers.

 

JIRA Applications

Property

Description

plugin.jira-integration.pullrequest.attribute.changesets.max=100

Controls the maximum number of changesets to retrieve when retrieving attributes associated with changesets of a pull-request. This value should be between 50 and 1000 as Bitbucket Server will enforce an lower bound of 50 issues and an upper bound of 1000 issues.

plugin.jira-integration.remote.page.max.issues=20

Controls the maximum number of issues to request from a JIRA application. This value should be between 5 and 50 as Bitbucket Server will enforce a lower bound of 5 issues and an upper bound of 50 issues.

plugin.jira-integration.remote.timeout.connection=5000

The connection timeout duration in milliseconds for requests to JIRA applications. This timeout occurs if a JIRA application server does not answer. e.g. the server has been shut down. This value should be between 2000 and 60000 as Bitbucket Server will enforce a lower bound of 2000ms and an upper bound of 60000ms. 

Value is in MILLISECONDS.

plugin.jira-integration.remote.timeout.socket=10000

The socket timeout duration in milliseconds for requests to JIRA applications. This timeout occurs if the connection to a JIRA application has been stalled or broken. This value should be between 2000 and 60000 as Bitbucket Server will enforce a lower bound of 2000ms and an upper bound of 60000ms.

Value is in MILLISECONDS.

JMX

Property

Description

jmx.enabled=true

Controls the publishing of Bitbucket Server specific statistics via JMX.

See Enabling JMX counters for performance monitoring.

Liquibase

Property

Description

liquibase.commit.block.size=10000

The maximum number of changes executed against a particular Liquibase database before a commit operation is performed. Very large values may cause DBMS to use excessive amounts of memory when operating within transaction boundaries. If the value of this property is less than one, then changes will not be committed until the end of the change set.

 

Logging

Logging levels for any number of loggers can be set in the bitbucket.properties file using the following format:

logging.logger.<name>=<level>

 

For example, to configure all classes in the com.atlassian.bitbucket package to DEBUG level:

logging.logger.com.atlassian.bitbucket=DEBUG

 

To adjust the ROOT logger, you use the special name ROOT (case-sensitive):

logging.logger.ROOT=INFO 

 

Notifications

Property

Description

plugin.bitbucket-notification.batch.min.wait.minutes=10

Controls the minimum time to wait for new notifications before sending the batch. This is the inactivity timeout.

Value is in MINUTES.

plugin.bitbucket-notification.batch.max.wait.minutes=30

Controls the maximum time to wait for new notifications before sending the batch. This is the staleness timeout.

Value is in MINUTES.

plugin.bitbucket-notification.mail.max.comment.size=2048

Controls the maximum allowed size of a single comment in characters (not bytes). Extra characters will be truncated.

plugin.bitbucket-notification.mail.max.description.size=2048

Controls the maximum allowed size of a single description in characters (not bytes). Extra characters will be truncated.

plugin.bitbucket-notification.mentions.enabled=true

Controls whether notifications for mentions are enabled.

plugin.bitbucket-notification.max.mentions=200

Controls the maximum number of allowed mentions in a single comment.

plugin.bitbucket-notification.sendmode.default=BATCHED

Controls the system default for notifications batching for users who have not set an explicit preference.

Value is either BATCHED or IMMEDIATE.

 

Paging

These properties control the maximum number of objects which may be returned on a page, regardless of how many were actually requested by the user. For example, if a user requests Integer.MAX_INT branches on a page, their request will be limited to the value set for page.max.branches

This is intended as a safeguard to prevent enormous requests from tying up the server for extended periods of time and then generating responses whose payload is prohibitively large. The defaults configured here represent a sane baseline, but may be overridden if necessary.

Property

Description

page.max.branches=1000

Maximum number of branches per page.

page.max.changes=1000

Maximum number of changes per page. Unlike other page limits, this is a hard limit; subsequent pages cannot be requested when the number of changes in a changeset exceeds this size.

page.max.commits=100

Maximum number of commits per page.

page.max.diff.lines=10000

Maximum number of segment lines (of any type, total) which may be returned for a single diff. Unlike other page limits, this is a hard limit; subsequent pages cannot be requested when a diff exceeds this size.

page.max.directory.children=500

Maximum number of directory entries which may be returned for a given directory.

page.max.directory.recursive.children=100000

Maximum number of file entries which may be returned for a recursive listing of a directory. A relatively high number as this is used by the file finder which needs to load the tree of files upfront.

page.max.groups=1000

Maximum number of groups per page.

page.max.index.results=50

Maximum number of changesets which may be returned from the index when querying by an indexed attribute. For example, this limits the number of changesets which may be returned when looking up commits against a JIRA application issue.

page.max.projects=1000

Maximum number of projects per page.

page.max.repositories=1000

Maximum number of repositories per page.

page.max.source.length=5000

Maximum length for any line returned from a given file when viewing source. This value truncates long lines. There is no mechanism for retrieving the truncated part short of downloading the entire file.

page.max.source.lines=5000

Maximum number of lines which may be returned from a given file when viewing source. This value breaks large files into multiple pages.

See also Display above.

page.max.tags=1000

Maximum number of tags per page.

page.max.users=1000

Maximum number of users per page.

page.max.pullrequests=100
Maximum number of pull requests per page.
page.scan.pullrequest.activity.size=500 The size of the page Bitbucket Server should use when scanning activities.
page.scan.pullrequest.activity.count=4 The number of pages of activities Bitbucket Server should scan before giving up.

 

Password reset

Property

Description

password.reset.validity.period=4320

Controls how long a password reset token remains valid for. Default period is 72 hours.

Value is in MINUTES.

 

Process execution

Property

Description

process.timeout.execution=120 

process.timeout.idle=60

Controls timeouts for external processes, such as Git and Hg. The idle timeout configures how long the command is allowed to run without producing any output. The execution timeout configures a hard upper limit on how long the command is allowed to run even if it is producing output. 

Values are in SECONDS. Using 0, or a negative value, disables the timeout completely.

USE AT YOUR OWN RISK!

 

Pull requests

Property

Description

pullrequest.diff.context=10

Defines the number of context lines to include around diff segments in pull request diffs. By default, Git only includes 3 lines. The default is 10, to try and include a bit more useful context around changes, until the ability to "expand" the context is implemented.

pullrequest.rescope.changesets.display=5

Defines the maximum number of changesets per type (either added or removed) to display in a rescope activity.

pullrequest.rescope.changesets.max=1000

Defines the absolute maximum number of changesets that will be evaluated when attempting to determine, for a given rescope activity, which changesets were added to or removed from a pull request. Adjusting this setting can have significant memory footprint impact on the system. It is not recommended to be changed, but the option is provided here to support unique use cases.

pullrequest.rescope.detail.threads=2

Defines the maximum number of threads to use for precalculating rescope details. These threads perform the requisite processing to determine the commits added and removed when a pull request is rescoped, where most rescopes do not add or remove any commits. Such "dead" rescopes are deleted during processing. The primary goal is to ensure all details have already been calculated when users try to view a pull request's overview.

pullrequest.rescope.drift.threads=4

Defines the maximum number of threads to use when processing comment drift for a pull request during rescope. Higher numbers here do not necessarily mean higher throughput! Performing comment drift will usually force a new merge to be created, which can be very I/O intensive. Having a substantial number of merges running at the same time can significantly reduce the speed of performing comment drift.

Readme parsing

Property

Description

plugin.bitbucket-readme.max.size=65536

Controls the maximum allowed size of a readme file to parse. 

Value is in BYTES.

 

Ref metadata

Property

Description

ref.metadata.timeout=2

Controls timeouts for retrieving metadata associated with a collection of refs from all metadata providers collectively.

This values is in SECONDS.

ref.metadata.max.request.count=100 Controls the maximum number of refs that can be used in a metadata query.

 

Ref restrictions

Property

Description

plugin.bitbucket-ref-restriction.case.insensitive=true Controls whether refs are matched case insensitively for ref restrictions.
plugin.ref-restriction.feature.splash=true Controls whether new users are shown a splash page when first viewing ref restrictions.
plugin.bitbucket-ref-restriction.max.resources=100 The maximum number of ref restrictions per repository.
plugin.bitbucket-ref-restriction.max.resource.entities=50 The maximum number of access grants per ref restriction.

 

Resource throttling

Adaptive throttling

Property Description
throttle.resource.scm-hosting.strategy=adaptive Specifies the strategy for throttling SCM hosting operations. Possible values are adaptive or fixed.
 throttle.resource.scm-hosting.adaptive.limit.min=1*${scaling.concurrency} When the adaptive strategy is enabled for throttling SCM hosting operations, this sets the lower limit on the number of SCM hosting operations, meaning pushes and pulls over HTTP or SSH, which may be running concurrently.
throttle.resource.scm-hosting.adaptive.limit.max=12*${scaling.concurrency} 
When the adaptive strategy is enabled for throttling SCM hosting operations, this sets the upper limit on the number of SCM hosting operations, meaning pushes and pulls over HTTP or SSH, which may be running concurrently. This is intended primarily to prevent pulls, which can be very memory-intensive, from exhausting a server's resources.
throttle.resource.scm-hosting.adaptive.cpu.target=0.75
When the adaptive strategy is enabled for throttling SCM hosting operations, this sets the target CPU utilisation for the machine (across all processors) which the system takes into consideration when calculating the current throttling limit.
This must be a value between  0.0 and  1.0 and is a percentage of the total available CPU power across all cores.
throttle.resource.scm-hosting.fixed.limit=1.5*${scaling.concurrency}
When the fixed strategy is enabled for throttling SCM hosting operations, this limits the number of SCM hosting operations, meaning pushes and pulls over HTTP or SSH, which may be running concurrently. This is intended primarily to prevent pulls, which can be very memory-intensive, from exhausting a server's resources.
There is limited support for mathematical expressions; +, -, *, / and () are supported.

Fixed throttling (deprecated)

As of Bitbucket Server 4.11, the property throttle.resource.scm-hosting is deprecated and is replaced with a number of other properties to configure adaptive throttling and the original fixed throttling.


Property

Description

throttle.resource.scm-command=25

Limits the number of operations that support the UI , such as git diff , git blame , or git rev-list , that can run concurrently. This is intended to prevent these SCM commands from competing with the running of push and pull operations.

throttle.resource.scm-command.timeout=2

Controls how long threads will wait for SCM commands to complete when the system is already running the maximum number of SCM commands.

Value is in SECONDS.

throttle.resource.scm-hosting=1.5*${scaling.concurrency}

Limits the number of SCM 'hosting' operations, such as git clone, git push and git pull over HTTP or SSH that may be running concurrently. This is intended primarily to prevent pulls, which can be very memory-intensive, from pinning a server's resources.  There is limited support for mathematical expressions; +,-,*,\ and () are supported. You can also use the ${scaling.concurrency} variable which is resolved to the number of CPUs that are available.

throttle.resource.scm-hosting.timeout=300

Controls how long threads will wait for SCM hosting operations to complete when the system is already running the maximum number of SCM hosting operations.

Value is in SECONDS.

throttle.resource.busy.message.timeout=5

Controls how long a warning banner is displayed in the UI after a request is rejected due to excessive load. 

Value is in MINUTES. Using 0, or a negative value, disables displaying the banner. 

This is deprecated and replaced by server.busy.on.ticket.rejected.within, It is due to be removed in Bitbucket Server 3.0.

 

SCM – Cache

See Scaling Bitbucket Server for Continuous Integration performance for more information about using the SCM Cache Plugin for Bitbucket Server.

Property Description
plugin.bitbucket-scm-cache.expiry.check.interval=30

Controls how frequently expired caches are checked and deleted from disk.

Value is in SECONDS.

plugin.bitbucket-scm-cache.eviction.hysteresis=1073741824

When eviction is triggered the amount of disk space requested for eviction is calculated as
(eviction.hysteresis + eviction.trigger.free.space – free space under <Bitbucket home directory>/caches)

Value is in BYTES.

plugin.bitbucket-scm-cache.eviction.trigger.free.space=6442450944

Controls the threshold at which eviction is triggered in terms of free space available on disk (specifically under <Bitbucket home directory>/caches)

Value is in BYTES.

plugin.bitbucket-scm-cache.minimum.free.space=5368709120

Controls how much space needs to be available on disk (specifically under <Bitbucket home directory>/caches) for caching to be enabled. This setting ensures that the cache plugin does not fill up the disk.

Value is in BYTES.

plugin.bitbucket-scm-cache.protocols=HTTP,SSH
Controls which protocols caching is applied to. The HTTP value encapsulates both http and https.
plugin.bitbucket-scm-cache.refs.enabled=false
Controls whether ref advertisement operations are cached.
plugin.bitbucket-scm-cache.refs.ttl=60

Controls how long the caches for ref advertisements are kept around when there no changes to the repository.

Caches are automatically invalidated when someone pushes to a repository or when a pull request is merged.

Time is in SECONDS.

plugin.bitbucket-scm-cache.upload-pack.enabled=true

Controls whether clone operations are cached.

plugin.bitbucket-scm-cache.upload-pack.ttl=14400

Controls how long the caches for clone operations are kept around when there no changes to the repository.

Caches are automatically invalidated when someone pushes to a repository or when a pull request is merged.

Time is in SECONDS.

 

SCM – Git

Property

Description

plugin.bitbucket-git.path.executable=git

Defines the default path to the Git executable. On Windows machines, the .exe suffix will be added to the configured value automatically if it is not present. In general, "git" should be an acceptable default for every platform, here, assuming that it will be available in the runtime user's PATH. 

With the new path searching performed by DefaultGitBinaryHelper, setting a default value here is unnecessary, as the plugin will quickly discard the value. This is left here purely for documenting how to set an explicit path.

plugin.bitbucket-git.path.libexec=

Defines the path to the Git libexec directory (containing the git-core directory). This path is hard-coded into the Git executable and is used for forking processes like git-http-backend. If this value is set, Bitbucket Server will directly fork out those processes. This eliminates an unnecessary fork (git -> git-http-backend) and may improve scalability.

plugin.bitbucket-git.backend.http.buffer.size=32768

Defines the buffer size in bytes which is used when marshaling data between the Git process and the HTTP socket.

plugin.bitbucket-git.backend.ssh.buffer.size=32768

Defines the buffer size in bytes which is used when marshaling data between the Git process and the SSH socket.

plugin.bitbucket-git.backend.timeout.idle=1800

Defines the idle timeout for push/pull processes, applying a limit to how long the operation is allowed to execute without either producing output or consuming input. The default value is 30 minutes. 

This value is in SECONDS.

plugin.bitbucket-git.backend.timeout.execution=86400

Defines the execution timeout for push/pull processes, applying a hard limit to how long the operation is allowed to run even if it is producing output or reading input. The default value is 1 day. 

This value is in SECONDS.

plugin.bitbucket-git.diff.renames=copies

Defines whether copy and/or rename detection should be performed. By default, both rename and copy detection are performed. Only files modified in the same commit are considered as rename or copy origins, to minimize overhead.

The possible settings are: 

  • copy or copies – applies --find-copies
  • rename or renames – applies --find-renames
  • off – disables rename and copy detection 

When using copy or copies, the value may optionally be suffixed with a "+" to use --find-copies-harder. This setting should be used with caution, as it can be very expensive. It considers every file in the repository, even files not modified in the same commit, as possible origins for copies. 

When copy and/or rename detection is enabled plugin.bitbucket-git.diff.renames.threshold can be used control the 
similarity index required for a change to be identified as a copy or rename.

plugin.bitbucket-git.diff.renames.threshold=50

Defines the threshold, as a percentage, for a file to be detected as a rename or a copy. This setting is only applied if copy and/or rename detection is enabled. The default threshold applied is 50% similarity (defined in Git itself). 

Git diff and Git diff-tree do not honor 100 (identical files only) for the threshold. They ignore the threshold and apply the default 50% threshold instead. A configured threshold of 100 will be applied as 99. Similarly, a configured threshold that is 0, or negative, will be applied as 1.

plugin.bitbucket-git.environment.variablesize=2000

Defines the maximum number of characters that can be added to a single environment variable. Different operating systems (and even different versions of the same operating system) have different hard limitations they apply to  environment variables. This default is intended to be low enough to work on all supported platforms out of the box, but still high enough to be usable. It is configurable in case it proves to be too high on some platform.

plugin.bitbucket-git.pullrequest.merge.auto.forceadd=false

Defines whether conflicted files should be added to the index using Git add --force, during automatic merges. By default, this behavior is off – simple Git add is "safer". However, when merging across branches with discrepant .Gitignore settings, enabling this setting may allow the system to create a conflicted diff (where without it a diff to the common ancestor will be shown instead). 

Note: This value has no effect on real pull request merges. It is only applied during automatic merges, for producing a pull request's change tree and diff.

plugin.bitbucket-git.pullrequest.merge.auto.timeout=120

Defines the maximum amount of time any command used to perform a merge to support the "merge" diff mode is allowed to execute or idle. Because the commands used generally do not produce output, there is no separate idle timeout. 

This value is in SECONDS.

plugin.bitbucket-git.pullrequest.merge.real.timeout=300

Defines the maximum amount of time any command used to merge a pull request is allowed to execute or idle. Because the commands used generally do not produce output, there is no separate idle timeout. 

This value is in SECONDS.

plugin.bitbucket-git.repository.size.timeout=75

Defines the maximum amount of time used to calculate the size of a single repository. Installations with many repositories and/or remote storage might consider a lower value.

This value is in MILLISECONDS.

 

Server busy banners

Property

Description

server.busy.on.ticket.rejected.within=5

Controls how long a warning banner is displayed in the UI after a request is rejected due to excessive load. 

Value is in MINUTES. Using 0, or a negative value, disables displaying the banner.

server.busy.on.queue.time=60

Controls how long requests need to be queued before they cause a warning banner to appear. 

Value is in SECONDS. Using 0, or a negative value, disables displaying the banner.

 

Setup automation

If these properties are specified in bitbucket.properties when the Setup Wizard runs after installing Bitbucket Server, then those values will be used, and the Setup Wizard will not display the corresponding configuration screens.

You can use these properties to automate Bitbucket Server setup and remove the need to interact with the Bitbucket Server Setup Wizard when provisioning Bitbucket Server. See Automated setup for Bitbucket Server.

Property Description
setup.displayName=displayName The display name for the Bitbucket Server instance.
setup.baseUrl= https://bitbucket.yourcompany.com The base URL to use for the Bitbucket Server instance.
setup.license=AAAB...\u000a1ev...\u000aA4N...

The Bitbucket Server license.

Use the the \u000 character to not break the license over multiple lines.

setup.sysadmin.username=username Credentials for the system admin account.
setup.sysadmin.password=password
setup.sysadmin.displayName=John Doe

The display name for the system admin account.

setup.sysadmin.emailAddress=sysadmin@yourcompany.com The email address for the system admin account.

SMTP

Property

Description

mail.timeout.connect=60

mail.timeout.send=60 

mail.test.timeout.connect=30

mail.test.timeout.send=30

Controls timeouts for establishing an SMTP connection and sending an e-mail. Shorter timeouts should be applied for when sending test e-mails, as the test occurs in user time. 

Values are in SECONDS.

mail.error.pause.log=300

Controls how frequently logs will go to the standard log file about mail sending errors. All errors are logged to the atlassian-bitbucket-mail.log file, but Bitbucket Server will periodically log a warning to the standard log file if there are errors sending messages. 

Value is in SECONDS.

mail.error.pause.retry=5

Controls how long Bitbucket Server will wait before retrying to send a message if an error occurs. 

Value is in SECONDS.

mail.threads=1

Controls the number of threads to use for sending emails. Setting this to a higher value will put greater load on your mail server when Bitbucket Server generates a lot of emails, but will make Bitbucket Server clear its internal queue faster.

mail.max.message.size=1048576

Controls the maximum allowed size of a single mail message, which is the sum of the subject and body sizes.

Value is in BYTES.

mail.max.queue.size=157286400

Controls the maximum allowed size for the mail queue (any new message will be rejected if the mail queue reaches that size).

Value is in BYTES.

 

SSH command execution

Property

Description

plugin.ssh.command.timeout.idle=86400

Controls timeouts for all SSH commands, such as those that service Git and hg operations over SSH. The idle timeout configures how long the command is allowed to run without writing any output to the client. For SCM commands, the plugin.*.backend.timeout.idle properties defined above will be applied to the underlying process. The default value is 1 day. 

Value is in SECONDS.

SSH security

Property

Description

plugin.ssh.disabled.ciphers

Controls which default ciphers are disabled when executing all SSH commands. Non existent ciphers are ignored. Names are case sensitive.

Example value: arcfour128,3des-cbc

To enable additional ciphers see the KB article Disable default SSH algorithms.

plugin.ssh.disabled.key.exchanges

Controls which default key exchange algorithms are disabled when executing all SSH commands. Non existent key exchange algorithms are ignored. Names are case sensitive.

Example value: ecdh-sha2-nistp256,ecdh-sha2-nistp384

To enable additional key exchange algorithms see the KB article Disable default SSH algorithms.

plugin.ssh.disabled.macs

Controls which default macs are disabled when executing all SSH commands. Non existent macs are ignored. Names are case sensitive.

Example value: hmac-sha1-96,hmac-md5-96,hmac-md5

 To enable additional macs see the KB article Disable default SSH algorithms .

Syntax highlighting

See Configuring syntax highlighting for file extensions for more information.

Bitbucket Server applies syntax highlighting to diffs as well as source files.

Property

Description

syntax.highlighter.<MIME type>.executables=exe1,exe2

Controls the language highlighter used for a given set of hashbang executables.

The <MIME type> refers to the MIME type CodeMirror uses.

syntax.highlighter.<MIME type>.extensions=ext1,ext2

Controls the language highlighter used for a given set of file extensions.

The <MIME type> refers to the MIME types CodeMirror uses.

Webhooks

See POST service webhook for Bitbucket Server for more information.

Property Description
plugin.com.atlassian.bitbucket.plugin.hook.threadPoolCoreSize=2
Core size of thread pool – the default number of concurrent hooks notifications.
plugin.com.atlassian.bitbucket.plugin.hook.threadPoolMaxSize=3
Maximal size of thread pool – the maximum number of concurrent hooks notifications.
plugin.com.atlassian.bitbucket.plugin.hook.queueSize=1024

The maximum size of the queue which holds queued requests that are yet to be sent.

When this size is exceeded the oldest unsent message will be dropped and a warning message logged.

plugin.com.atlassian.bitbucket.plugin.hook.connectionTimeout=10000

Connection timeout for hook request in MILLISECONDS.

When the connection times out a warning message will be logged.

plugin.com.atlassian.bitbucket.plugin.hook.changesetsLimit=500
Limit of maximum count of changesets that will be sent in the POST data for a single ref change.
plugin.com.atlassian.bitbucket.plugin.hook.changesLimit=100
Limit of maximum count of changes for a single changeset in the POST data.
Last modified on Jan 20, 2017

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.