Bitbucket Server config properties
This page describes the configuration properties that can be used to control behavior in Bitbucket Server 5.0. Create the bitbucket.properties
file, in the shared folder of your home directory, and add the system properties you need, use the standard format for Java properties files.
Note that bitbucket.properties
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:
Analytics
Default value | Description |
---|---|
analytics.aws.enabled | |
true | Controls whether AWS instance analytics events are published. This setting only has an effect if analytics is enabled. |
Application mode
Default value | Description |
---|---|
application.mode | |
default | Controls what mode Bitbucket is in - currently "mirror" and "default" are supported |
Attachments
Default value | Description |
---|---|
attachment.upload.max.size | |
10485760 | Defines the largest single attachment the system will allow. Attachments larger than this will be rejected without ever being stored locally. This setting applies to all uploaded data, including avatars. Some types may have their own further restriction they apply on top of this. However, for such types, the file will be stored locally prior to that secondary limit being applied. If that secondary limit is higher than this limit, this limit is the one that will be applied. This value is in bytes. |
Audit
These properties control the auditing feature, determining the number of audit entries logged, or stored in the database, and the size of those entries. Changing these settings will only affect new audit entries.
Increasing the amount of auditing done may have an adverse effect on performance.
Default value | Description |
---|---|
audit.highest.priority.to.log | |
HIGH | Defines the lowest priority audit events that will be logged. Setting the value to Refer to the levels for the various events. This does not affect events displayed in the Audit log screens for projects and repositories. Valid values are: |
audit.details.max.length | |
1024 | Defines the number of characters that can be can stored as details in 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.
Default value | Description |
---|---|
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:
|
auth.remember-me.cookie.name | |
_atl_bitbucket_remember_me | Defines the cookie name used for the remember-me authentication |
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. This value is in days. |
auth.remember-me.token.grace.period | |
60 | How long a token can be re-used for authentication after it has been used to authenticate . This setting allows a grace period to allow parallel authentication attempts to succeed. This commonly happens when a browser is started and opens multiple tabs at once. This value is in seconds |
auth.remember-me.token.cleanup.interval | |
300 | Controls how frequently expired remember-me tokens are cleaned up. This value is in minutes |
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 the system is connected to a Crowd directory that is configured for SSO. |
plugin.auth-crowd.sso.config.ttl | |
15 | The auth plugin caches the SSO configuration that is retrieved from the remote Crowd server. This setting controls the time to live of that cache. This value is in minutes. |
plugin.auth-crowd.sso.config.error.wait | |
1 | If an error occurs while retrieving the SSO configuration from the remote Crowd server, the system will wait this long before retrying. The wait time between subsequent attempts is incremented exponentially (1s -> 1.5s -> 2.3s -> 3.4s, etc). The wait time is capped at the configured TTL. This value is in seconds. |
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 used for communication with the Crowd server. A value of zero indicates that there is no connection timeout. This value is in milliseconds. |
plugin.auth-crowd.sso.socket.timeout | |
20000 | The socket timeout. You may wish to override the default value if the latency to the Crowd server is high. This value is in milliseconds. |
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, each HTTP request will be authenticated with the Crowd server. |
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. |
Avatars
Default value | Description |
---|---|
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. This 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. This value is in bytes. |
avatar.url.default | |
mm | 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. |
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 The following format parameters are available:
|
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 The following format parameters are available:
|
Backups
Default value | Description |
---|---|
backup.drain.scm.timeout | |
60 | Controls how long the backup should wait for outstanding SCM operations to complete before failing. This value is in seconds. |
backup.drain.db.timeout | |
90 | Draining database connections during backup happens in two stages. Stage 1 passively waits a set amount of time for all connections to be returned to the pool. If connections are still leased when backup.drain.db.timeout seconds has elapsed then stage 2 begins and will interrupt the owning threads, wait backup.drain.db.force.timeout seconds and finally attempt to roll back and close any remaining connections. In stage 1 of draining connections during backup, this setting controls how long the backup should wait for outstanding database operations to complete before moving to stage 2. See backup.drain.db.force.timeout This value is in seconds. |
backup.drain.db.force.timeout | |
30 | In stage 2 of draining connections during backup, this property controls how long the backup process should wait (after interrupting the owning threads) for those threads to release the connections before forcibly rolling back and closing them. Note if all connections have been returned to the pool stage 2 is skipped and so this property has no effect. A negative value will skip stage 2 completely. See backup.drain.db.timeout This value is in seconds. |
Branch Information
Default value | Description |
---|---|
plugin.bitbucket-branch-information.timeout | |
5 | Controls timeouts for retrieving branch information, which for large repositories can be quite slow and consume a single Git process. This value is in seconds. |
plugin.bitbucket-branch-information.max.branches | |
1000 | Controls the maximum number of branches that are shown the user |
Branch Utils
Default value | Description |
---|---|
plugin.bitbucket-auto-merge.limit | |
30 | Defines the maximum number of merges allowed along in single automatic merge chain. If the number of merges included in the chain exceeds this limit, the entire chain will be skipped. Setting this limit to 0 means automatic merging is effectively disabled, since the merge chain must always be empty. |
plugin.bitbucket-auto-merge.timeout | |
300 | Defines the maximum amount of time any command used to perform a single automatic merge from the chain is allowed to execute or idle. Since an automatic merge may require a series of different commands at the SCM level, this timeout does not define the upper bound for how long the overall merge process might take; it only defines the duration allotted to any single command. This value is in seconds. |
plugin.bitbucket-branch-model.version.separator | |
[_\\-.+] | The version component separator for branch model. This value is a regular expression pattern that is used to split branch names parsed as version strings into separate components for comparison. The default value results in any of the following 4 characters being used for comparison: _ - + . |
plugin.bitbucket-branch-model.validation.prefix.length | |
30 | The maximum allowed length of branch prefixes in branch model |
Clustering
Default value | Description |
---|---|
hazelcast.enterprise.license | |
Specifies a Hazelcast enterprise license. An enterprise license is not required, but supplying one will unlock additional Hazelcast functionality, such as the ability to use the Hazelcast Management Center with clusters containing more than 2 nodes, which may be useful in production environments. | |
hazelcast.managementcenter.url | |
Specifies the URL where the Hazelcast Management Center is running. When a URL is configured each node in the cluster will connect to the Management Center at that URL and broadcast its status. | |
hazelcast.group.name | |
${user.name} | Specifies the cluster group the instance should join. This can be used, for example, to partition development and production clusters. |
hazelcast.group.password | |
${user.name} | The password required to join the specified cluster group. |
hazelcast.http.sessions | |
local | Specifies how HTTP sessions should be managed. The following values are supported:
|
hazelcast.network.aws | |
false | A |
hazelcast.network.aws.iam.role | |
If | |
hazelcast.network.aws.access.key | |
If | |
hazelcast.network.aws.secret.key | |
If | |
hazelcast.network.aws.region | |
The AWS region to query. If empty, Hazelcast's default ("us-east-1") is used. If set, it will override any value for "hazelcast.network.aws.host.header" (see below). | |
hazelcast.network.aws.host.header | |
The Host: header to use when querying the AWS EC2 API. If empty, then Hazelcast's default ("ec2.amazonaws.com") is used. If set, then "hazelcast.network.aws.region" shouldn't be set as it will override this property. | |
hazelcast.network.aws.security.group.name | |
There are 2 mechanisms for filtering out AWS instances and these mechanisms can be combined (AND).
| |
hazelcast.network.aws.tag.key | |
The AWS tag key to use to filter instances to form a cluster with. | |
hazelcast.network.aws.tag.value | |
The AWS tag value to use to filter instances to form a cluster with. | |
hazelcast.network.multicast | |
false | A |
hazelcast.network.multicast.address | |
The multicast address for the cluster, used to locate members when multicast discovery is enabled. If no value is set here, Hazelcast's default (224.2.2.3) is used. This value should not need to be configured explicitly on most networks. | |
hazelcast.network.multicast.port | |
${hazelcast.port} | The multicast port to bind to. By default, this will be the |
hazelcast.network.tcpip | |
false | A |
hazelcast.network.tcpip.members | |
localhost:5701,localhost:5702 | List of members that Hazelcast nodes should connect to when TCP/IP is enabled. These nodes function as root nodes, allowing cluster nodes to discover each other. This comma-separated list does not need to include every node in the cluster. When new nodes join they will use the connected node to find the other cluster nodes. |
hazelcast.port | |
5701 | The network port where Hazelcast will listen for cluster members. If multiple instances are run on the same server Hazelcast will automatically increment this value for additional nodes. |
Comment Likes
Default value | Description |
---|---|
plugin.bitbucket-comment-likes.max.resources | |
500 | The maximum number of comment likes associated with a single comment. The system will allow to create more likes than this number, but the results of API calls to get likes will be strictly limited to the value configured here, with appropriate warnings recorded in the application logs. |
plugin.bitbucket-comment-likes.max.page | |
100 | The maximum size of a page of comment likes |
Commit Indexing
These properties control how commits are indexed when after pushes or pull request merges.
Default value | Description |
---|---|
indexing.max.threads | |
4 | 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 commits 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.queue.timeout.poll | |
60 | Controls how long indexing processes are allowed to wait for the next commit to be made available in the commit queue before assuming the process that retrieves the commits is stuck and giving up. This value is in seconds. |
indexing.queue.size | |
1024 | Defines the size of the queue that will be used for indexing. When the limit is reached the program will block until there is space in the queue to add any required new items. |
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. This value is in seconds. |
indexing.snapshot.timeout.execution | |
120 | Controls how long snapshot generation, which captures the state of a repository's branches and tags, is allowed to execute before it is interrupted. This timeout is applied whether the process is producing output or not. This value is in seconds. |
indexing.snapshot.timeout.idle | |
${indexing.snapshot.timeout.execution} | Controls how long snapshot generation, which captures the state of a repository's branches and tags, is allowed to run without producing output before it is interrupted. This value is in seconds. |
Commit graph cache
Default value | Description |
---|---|
commit.graph.cache.min.free.space | |
1073741824 | Controls how much space needs to be available on disk (specifically under <BITBUCKET_HOME>/caches) for caching to be enabled. This setting ensures that the cache plugin does not fill up the disk. This 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. |
Commits
Default value | Description |
---|---|
commit.diff.context | |
10 | Defines the number of context lines to include around diff segments in commit diffs. |
commit.lastmodified.timeout | |
120 | Defines the timeout for streaming last modifications for files under a given path, applying a limit to how long the traversal can run before the process is canceled. This timeout is applied as both the execution and idle timeout. This value is in seconds. |
commit.list.follow.renames | |
true | Defines whether file history commands in the UI should follow renames by default. This feature can be disabled as it may cause significant load for repositories with long commit logs. |
commit.message.max | |
262144 | Controls the maximum length of the commit message to be loaded when retrieving a single commit from the SCM. Commit messages longer than this limit will be truncated. The default limit is high enough to not affect processing for the general case, but protects the system from consuming too much memory in exceptional cases. |
commit.message.bulk.max | |
16384 | Controls the maximum length of the commit message to be loaded when bulk retrieving a commits from the SCM. Commit messages longer than this limit will be truncated. The default limit is high enough to not affect processing for the common case, but protects the system from consuming too much memory when many commits have long messages. |
Database
Database properties allow explicitly configuring the database the system should use. They may be configured directly in bitbucket.properties
, or they may be specified during setup. Existing systems may be migrated to a new database using the in-app migration feature.
If no database is explicitly configured, an internal database will be used automatically. Which internal database is used is not guaranteed.
If the jdbc.driver
, jdbc.url
, jdbc.password
and jdbc.user
properties are specified in bitbucket.properties
when the Setup Wizard runs after installation, then those values will be used, and the Setup Wizard will not display the database configuration screen.
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.
Default value | Description |
---|---|
jdbc.driver | |
org.h2.Driver | The JDBC driver class that should be used to connect to the database. The system uses an internal database by default, and stores its data in the home directory. The following JDBC drivers are bundled with the distribution:
The JDBC drivers for MySQL are not bundled (due to licensing restrictions) so you will need to download and install the driver yourself. See Connecting to MySQL for instructions. |
jdbc.url | |
jdbc:h2:${bitbucket.shared.home}/data/db;MVCC=TRUE;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;TRACE_LEVEL_FILE=4 | This is the JDBC URL that will be used to connect to the database. This URL varies depending on the database you are connecting to. Please consult the documentation for your JDBC driver to determine the correct URL. |
jdbc.user | |
sa | This is the user that will be used to authenticate with the database. This user must have full DDL rights. It must be able to create, alter and drop tables, indexes, constraints, and other SQL objects, as well as being able to create and destroy temporary tables. |
jdbc.password | |
The password that the user defined by |
Database Pool
These properties control the database pool. The pool implementation used is HikariCP. Documentation for these settings can be found on the wiki.
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.
Default value | 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.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. |
Database Schema
These properties control aspects of how the database schema is managed.
Default value | Description |
---|---|
db.schema.lock.maxWait | |
30 | Defines the maximum amount of time the system can wait to acquire the schema lock. Shorter values will prevent long delays on server startup when the lock is held by another instance or, more likely, when the lock was not released properly because a previous start was interrupted while holding the lock. This can happen when the system is killed while it is attempting to update its schema. This value is in seconds. |
db.schema.lock.pollInterval | |
5 | Defines the amount of time to wait between attempts to acquire the schema lock. Slower polling produces less load, but may delay acquiring the lock. This value is in seconds. |
Display
These properties control maximum limits of what will be displayed in the web UI.
Default value | Description |
---|---|
display.max.source.lines | |
20000 | Controls how many lines of a source file will be retrieved before a warning banner is shown and the user is encouraged to download the raw file for further inspection. This property relates to |
Downloads
Default value | Description |
---|---|
http.download.raw.policy | |
Smart | Controls the download policy for raw content. Possible values are:
These options are case-sensitive and defined in |
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.
Warning: 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.
Default value | 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.
Default value | Description |
---|---|
event.dispatcher.core.threads | |
0.8*${scaling.concurrency} | The minimum number of threads that is available to the event dispatcher. The |
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 this configured limit has not been reached. |
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.queue.rejectioncooldown | |
10 | When an event cannot be dispatched because the queue is full, the stack traces of all busy event processing threads will be logged. This defines the cooldown that is applied to that logging to prevent spamming the stacks in the logs on every rejected event. This value is in minutes |
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. This value is in seconds. |
Executor
Controls the thread pool that is made available to plugins for asynchronous processing.
Default value | Description |
---|---|
executor.max.threads | |
${scaling.concurrency} | Controls the maximum number of threads allowed in the common |
Features
These 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 instance-level configuration for a feature is overridden. It also means a user's permissions are irrelevant; a feature is still disabled even if the user has the system admin permission.
Default value | Description |
---|---|
feature.attachments | |
true | Controls whether users are allowed to upload attachments to repositories they have access to. If this feature is enabled and later disabled, attachments which have already been uploaded are not automatically removed. |
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 a set limit for failed logins using either the web interface or Git hosting will be be required to authenticate in the web interface and successfully submit a CAPTCHA before continuing. Disabling this will remove this restriction and allow users to incorrectly authenticate as many times as they like without penalty. Warning: It is strongly recommended to keep this setting enabled. Disabling it has the following ramifications:
|
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.smart.mirrors | |
true | Controls whether smart mirrors can be connected to the instance. Note that this feature is only available for Data Center installations |
feature.personal.repos | |
true | Controls whether personal repositories can be created. When set to |
feature.public.access | |
true | Public access allows anonymous users to be granted access to projects and repositories for# read operations including cloning and browsing repositories. This is controlled normally by project and repository administrators but can be switched off system wide by setting this property to false. This can be useful in sensitive environments. |
feature.getting.started.page | |
true | Controls whether new users are redirected to a getting started page after their first login. |
feature.user.time.zone.onboarding | |
true | Controls whether users with mismatching time zones are shown an alert prompting them to change their user time zone. |
feature.file.editor | |
true | Controls whether users can edit repository files in the browser and via REST. When set to |
File editor
Default value | Description |
---|---|
content.upload.max.size | |
5242880 | Controls the maximum allowed file size when editing a file through the browser or file edit REST endpoint This value is in bytes. Default is 5 MiB |
Fork Syncing (Ref Syncing)
Default value | Description |
---|---|
plugin.bitbucket-repository-ref-sync.fetch.timeout | |
300 | Defines the maximum amount of time fetch commands used to synchronize branches in bulk are allowed to execute or idle. Because fetch commands generally produce the majority of their output upon completion, there is no separate idle timeout. The default value is 5 minutes. This value is in seconds. |
plugin.bitbucket-repository-ref-sync.merge.timeout | |
300 | Defines the maximum amount of time any command used to merge upstream changes into the equivalent branch in a fork is allowed to execute or idle. Since merging branches may require a series of different commands at the SCM level, this timeout does not define the upper bound for how long the overall merge process might take; it only defines the duration allotted to any single command. This value is in seconds. |
plugin.bitbucket-repository-ref-sync.threads | |
3 | Controls the number of threads used for ref synchronization. Higher values here will help synchronization keep up with upstream updates, but may produce noticeable additional server load. |
Hibernate
Default value | Description |
---|---|
hibernate.format_sql | |
${hibernate.show_sql} | When |
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, not by customers. |
Importer
Default value | Description |
---|---|
plugin.importer.external.source.request.socket.timeout | |
30 | Controls how long requests to external repository source servers can continue without producing any data before the importer gives up. This value is in seconds. |
plugin.importer.external.source.request.timeout | |
30 | Controls how long requests to external repository source servers can proceed before the importer gives up. This value is in seconds. |
plugin.importer.import.repository.thread.max | |
8 | Maximal size of thread pool – the maximum number of concurrent repository imports. |
plugin.importer.repository.fetch.timeout.execution | |
360 | Defines the execution timeout for fetch 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 6 hours. This value is in minutes. |
plugin.importer.repository.fetch.timeout.idle | |
60 | Defines the idle timeout for fetch processes, applying a limit to how long the operation is allowed to execute without either producing output or consuming input. The default value is 60 minutes. This value is in minutes. |
JIRA
Default value | Description |
---|---|
plugin.jira-integration.pullrequest.attribute.commits.max | |
100 | Controls the maximum number of commits to retrieve when retrieving attributes associated with commits of a pull-request. This value must be between 50 and 1000, which are imposed as lower and upper bounds on any value specified here. |
plugin.jira-integration.remote.page.max.issues | |
20 | Controls the maximum number of issues to request from JIRA. This value must be between 5 and 50, which are imposed as lower and upper bounds on any value specified here. |
plugin.jira-integration.remote.timeout.connection | |
5000 | The connection timeout duration in milliseconds for requests to JIRA. This timeout occurs if the JIRA server does not answer. e.g. the server has been shut down. This value must be between 2000 and 60000, which are imposed as lower and upper bounds on any value specified here. This value is in milliseconds. |
plugin.jira-integration.remote.timeout.socket | |
10000 | The socket timeout duration in milliseconds for requests to JIRA. This timeout occurs if the connection to JIRA has been stalled or broken. This value must be between 2000 and 60000, which are imposed as lower and upper bounds on any value specified here. This value is in milliseconds. |
JIRA Automatic Transition Trigger Events
These properties control whether events should be converted into Remote Events so they can trigger automatic issue transitions in JIRA.
Default value | Description |
---|---|
plugin.dev-summary.pr.commits.threshold | |
${plugin.jira-integration.pullrequest.attribute.commits.max} | Limit the number of commits to be scanned per pull request |
plugin.dev-summary.pr.events.enabled | |
true | Controls whether pull request events should be published |
plugin.dev-summary.branch.events.threshold | |
10 | Limit the number of branch events sent per synchronization If set to zero then no branch events will be published |
plugin.dev-summary.commit.events.threshold | |
100 | Limit the number of commit events sent per synchronization If set to zero then no commit events will be published |
plugin.dev-summary.issuechanged.events.threshold | |
100000 | Limit the number of issue changed events sent per synchronization. Issue changed events are based on the issue keys within the commit messages for commit events or within branch names for branch events. For branches, this value is the maximum of branches considered. For commits, this value is the maximum number of commits considered. If set to zero then no issue changed events will be published |
plugin.dev-summary.issue.commits.threshold | |
100 | Limit the number of commits to be returned per issue |
plugin.dev-summary.repository.trigger.settings.enabled | |
false | Controls whether the JIRA triggers page is visible on repository settings |
JMX
See Enabling JMX counters for performance monitoring.
Default value | Description |
---|---|
jmx.enabled | |
false | Controls whether JMX management interfaces for the system and its libraries are registered. Note: Some libraries may register their JMX management interfaces regardless of this setting. |
Job Scheduler
Controls the scheduler that processes background jobs submitted by the system and by plugins.
Default value | Description |
---|---|
scheduler.history.expiry.days | |
30 | Controls how long job history is remembered after it is last updated before it expires. Job history in the "RunDetails" class available to plugins from atlassian-scheduler is only valid for the last run of the job on the same cluster node. Calls to retrieve RunDetails for the same job on different cluster nodes may return different results. This value is in days. The value cannot be negative. |
scheduler.refresh.interval.minutes | |
1 | Controls the frequency at which the scheduler will automatically poll for changes to clustered jobs. If the value is positive, then the scheduler will refresh its queue of clustered jobs at the specified interval in minutes. If the value is 0 or negative, then jobs submitted on one cluster node will never be scheduled on other cluster nodes. It is not recommended to modify this setting unless recommended by Atlassian Support. This value is in minutes. Using 0, or a negative value, disables clustering of background jobs completely. |
scheduler.shutdown.timeout | |
15 | The number of seconds to wait for running jobs to end after calling 'shutdown' on the scheduler service. This value is in seconds. |
scheduler.worker.threads | |
4 | Controls the number of worker threads that will accept jobs from the queue on each cluster node. If the value is 0 or negative, then the scheduler's default of 4 threads will be used. |
Liquibase
Default value | 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 bitbucket.properties
using the following format:
logging.logger.{name}={level}
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
Migration
Draining database connections during database migration happens in two stages. Stage 1 passively waits a set amount of time for all connections to be returned to the pool. If connections are still leased when migration.drain.db.timeout seconds has elapsed then stage 2 begins and will interrupt the owning threads, wait migration.drain.db.force.timeout
seconds and finally attempt to roll back and close any remaining connections.
Default value | Description |
---|---|
migration.drain.db.timeout | |
${backup.drain.db.timeout} | In stage 1 of draining connections during migration, this setting controls how long the migration should wait for outstanding database operations to complete before moving to stage 2. See This value is in seconds. |
migration.drain.db.force.timeout | |
${backup.drain.db.force.timeout} | In stage 2 of draining connections during migration, this property controls how long the migration process should wait (after interrupting the owning threads) for those threads to release the connections before forcibly rolling back and closing them. Note if all connections have been returned to the pool stage 2 is skipped and so this property has no effect. A negative value will skip stage 2 completely. See This value is in seconds. |
Mirroring
Default value | Description |
---|---|
plugin.mirroring.upstream.url | |
<base-url of the upstream server> | Defines where the mirror server should be mirroring from. Only define this property for mirror servers. |
plugin.mirroring.upstream.namespace | |
<namespace of the upstream server> | Defines the namespace of the upstream server at initial registration, to be used in the clone URL for repositories mirrored from this server. Only used for mirror servers. |
plugin.mirroring.state.refresh.interval | |
1 | Controls how frequently the mirror will attempt to refresh its state from the upstream server. This value is in minutes |
plugin.mirroring.synchronization.delay.initial | |
20 | Controls how long after startup the first full synchronization should be attempted. This value is in seconds |
plugin.mirroring.synchronization.fetch.timeout.execution | |
172800 | Defines the execution timeout for fetch 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 48 hours. This value is in seconds. |
plugin.mirroring.synchronization.fetch.timeout.idle | |
1800 | Defines the idle timeout for fetch 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.mirroring.synchronization.interval | |
15 | Controls how frequently a full synchronization with the upstream server should run This value is in minutes |
plugin.mirroring.synchronization.max.failures | |
3 | Controls the number of consecutive failed synchronizations on a repository before the mirror gives up. |
plugin.mirroring.synchronization.repository.page.size.max | |
100 | Controls how large the pages should be when requesting upstream repositories |
plugin.mirroring.synchronization.threads | |
2 | Controls the maximum concurrency of repository synchronization tasks, i.e. the maximum number of concurrent fetches to the upstream server |
plugin.mirroring.upstream.auth.cache.ttl | |
300 | Controls how long to cache the result of authentication requests made against the primary server such that if the same credentials are provided to the mirror within that period, the same result is used to calculate the outcome of the authentication and a remote (network) calls for the authentication request is avoided. Note: this caches both authentication successes (valid username/password, SSH key registered to user) but also failures (incorrect username/password pairs, unknown SSH keys). Also note: that cache entries expire after they are inserted, not after the last access. Repeatedly making authentication requests to the mirror with the same credentials will not prevent expiry of the result from the cache. This value is in seconds. A positive value will cache an authentication result for the configured period. A non-positive value will disable the cache and cause all authenticated requests to be executed remotely every time. Defaults to 5 minutes. |
plugin.mirroring.upstream.auth.cache.max | |
-1 | Configures the maximum number of authentication cache entries. Cache entries for Bitbucket Server mirrors can be heavy for certain permission schemes so this setting can control how much memory is devoted to this cache. For Bitbucket Server mirrors, there is one cache entry consumed for each combination of {user credentials, authentication method (HTTP basic/SSH)} For bitbucket.org mirrors, there is one cache entry consumed for each combination of {user credentials, authentication method (HTTP basic/SSH), repository} A negative value indicates an unlimited cache. A zero value indicates the cache should be disabled. A positive value indicates a specific cache limit. Defaults to unlimited. |
plugin.mirroring.upstream.auth.cache.fallback.ttl | |
1800 | Controls the expiry of values in a secondary cache (separate to plugin.mirroring.upstream.auth.cache.expiry) which caches the result of authentication requests to be used to recover from remote authentication request fails for environmental or connectivity reasons. The types of problems this cache will try to overcome are network partition, request timeout, socket timeout, thread interruption, invalid HTTP response codes or entities from the primary. Note: this caches both authentication successes (valid username/password, SSH key registered to user) but also failures (incorrect username/password pairs, unknown SSH keys). Also note: that cache entries expire after they are inserted, not after the last access. Repeatedly making authentication requests to the mirror with the same credentials will not pause expiry of the result from the cache. This value is in seconds. A positive value will cache the authentication results for the configured period. If the value is postive and smaller than plugin.mirroring.upstream.auth.cache.expiry it will be adjusted upwards. A non-positive value will disable the cache and cause any failing authentication requests to not attempt recovery using a previously changed result thus failing any related authentication requests by clients. Defaults to half an hour. |
plugin.mirroring.upstream.auth.cache.fallback.max | |
-1 | Configures the maximum number of fallback authentication cache entries. Cache entries for Bitbucket Server mirrors can be heavy for certain permission schemes so this setting can control how much memory is devoted to this cache. For Bitbucket Server mirrors, there is one cache entry consumed for each combination of {user credentials, authentication method (HTTP basic/SSH)} For bitbucket.org mirrors, there is one cache entry consumed for each combination of {user credentials, authentication method (HTTP basic/SSH), repository} A negative value indicates an unlimited cache. A zero value indicates the cache should be disabled. A positive value indicates a specific cache limit. Defaults to unlimited. |
plugin.mirroring.upstream.request.socket.timeout | |
15 | Controls how long active requests to upstream servers can continue without producing any data before the mirror gives up. Must be a value smaller than plugin.ssh.auth.timeout my a decent margin if auth fallback caching is to be effective for socket timeouts This value is in seconds. |
plugin.mirroring.upstream.request.timeout | |
15 | Controls how long requests to upstream servers can proceed before the mirror gives up. Must be a value smaller than plugin.ssh.auth.timeout my a decent margin if auth fallback caching is to be effective for request timeouts This value is in seconds. |
Notifications
Default value | Description |
---|---|
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 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 | Default mode for sending notifications for users who have not set an explicit preference. This value is either |
plugin.bitbucket-notification.batch.min.wait.minutes | |
10 | The minimum time to wait for new notifications in a batch before sending it (inactivity timeout). This value is in minutes. |
plugin.bitbucket-notification.batch.max.wait.minutes | |
30 | The maximum time to wait since the first notification of a batch before sending it (staleness avoidance timeout). This value is in minutes. |
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 by customers if necessary.
Default value | 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 commit 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 | |
1000 | 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.granted.permissions | |
1000 | Maximum number of granted permissions per page. |
page.max.index.results | |
50 | Maximum number of commits which may be returned from the index when querying by an indexed attribute. For example, this limits the number of commits which may be returned when looking up commits against a JIRA issue. |
page.max.projects | |
1000 | Maximum number of projects per page. |
page.max.pullrequest.activities | |
500 | Maximum number of pull request activities per page. |
page.max.pullrequests | |
100 | Maximum number of pull requests 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 | |
${display.max.source.lines} | Maximum number of lines which may be returned from a given file when viewing source. This value breaks large files into multiple pages. This property relates to display.max.source.line in that up to (display.max.source.lines/page.max.source.lines) requests will be made to view the page. |
page.max.tags | |
1000 | Maximum number of tags per page. |
page.max.users | |
1000 | Maximum number of users per page. |
page.scan.pullrequest.activity.size | |
500 | The page size to use when searching activities to find a specific one. |
page.scan.pullrequest.activity.count | |
4 | The number of pages of activities to scan, when searching for a given activity, before giving up. |
Password Reset
Default value | Description |
---|---|
password.reset.validity.period | |
4320 | Controls how long a password reset token remains valid for. Default period is 72 hours. This value is in minutes. |
Process execution
Controls timeouts for external processes, such as git
.
Default value | Description |
---|---|
process.timeout.execution | |
120 | Configures a hard upper limit on how long the command is allowed to run even if it is producing output. This value is in seconds. Using 0, or a negative value, disables the timeout completely. |
process.timeout.idle | |
60 | The idle timeout configures how long the command is allowed to run without producing any output. This value is in seconds. Using 0, or a negative value, disables the timeout completely. |
process.windows.autoescapequotes | |
true | Configures whether or not to escape quotes for commands on Windows |
Pull Requests
Default value | Description |
---|---|
pullrequest.bulk.rescope.timeout | |
300 | Defines the maximum amount of time any command used to analyse the effects of ref changes to open pull requests (rescoping) is allowed to execute. For these commands, the standard idle timeout for processes applies. This value is in seconds |
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.merge.timeout | |
300 | Defines the maximum amount of time any command used to merge a pull request is allowed to execute or idle. Since merging a pull request may require a series of different commands at the SCM level, this timeout does not define the upper bound for how long the overall merge process might take; it only defines the duration allotted to any single command. This value is in seconds. |
pullrequest.rescope.commits.display | |
5 | Defines the maximum number of commits per type (either added or removed) to display in a rescope activity. |
pullrequest.rescope.commits.max | |
1000 | Defines the absolute maximum number of commits that will be evaluated when attempting to determine, for a given rescope activity, which commits 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.cleanup.interval | |
30 | Controls how frequently empty rescope activities are cleaned up. Because pull requests rescope very frequently it is important to remove empty rescopes from the database to keep activity queries performant. This value is in minutes. |
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.maxattempts | |
5 | Controls how many times comment drift will be retried when it fails. Certain failure types are considered to be unrecoverable and will not be retried regardless of this setting. Unrecoverable failures are logged. |
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. |
pullrequest.rescope.threads | |
1 | Defines the maximum number of threads to use for rescoping pull requests. |
Readme parsing
Default value | Description |
---|---|
plugin.bitbucket-readme.max.size | |
1048576 | Controls the maximum allowed size of a readme file to parse. This value is in bytes. Default is 1 MiB |
Ref Restrictions (Branch permissions)
Default value | 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. This count refers to each permission item, not each branch. High numbers of branch permissions will adversely impact the speed of pushes to the repository, so increasing this limit is not recommended. |
plugin.bitbucket-ref-restriction.max.resource.entities | |
50 | The maximum number of access grants per ref restriction. |
Ref metadata
Default value | 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 | Maximum number of refs that can be used in a metadata query. |
Repository shortcuts
Default value | Description |
---|---|
plugin.repository.shortcut.url.scheme.extended.whitelist | |
The extended whitelist for allowed URL schemes. The URL for a repository shortcut must begin with one of the schemes in the default whitelist or a scheme in this property. Schemes should be comma separated, e.g. 'scheme1:,scheme2:'. |
Resource Throttling
These properties define concurrent task limits for the ThrottleService, limiting the number of concurrent operations of a given type that may be run at once. This is intended to help prevent overwhelming the server hardware with running processes. Two settings are used to control the number of processes that are allowed to process in parallel: one for the web UI and one for 'hosting' operations (pushing and pulling commits, cloning repositories).
When the limit is reached for the given resource, the request will wait until a currently running request has completed. If no request completes within a configurable timeout, the request will be rejected.
When requests to the UI are rejected, users will see either a 501 error page indicating the server is under load, or a popup indicating part of the current page failed to load.
When SCM hosting commands (pull/push/clone) are rejected, it is messaged in multiple ways:
An error message is returned to the client, which the user will see on the command line: "Bitbucket is currently under heavy load and is not able to service your request. Please wait briefly and try your request again"
A warning message is logged for every time a request is rejected due to the resource limits, using the following format: "
A [scm-hosting] ticket could not be acquired (12/12)
"For five minutes after a request is rejected, a red banner will be displayed in the UI to warn that the server is reaching resource limits.
The underlying machine-level limits these are intended to prevent hitting are very OS- and hardware-dependent, so you may need to tune them for your instance. When hyperthreading is enabled for the server's CPUs, for example, it is likely that the default settings will allow sufficient concurrent operations to saturate the I/O on the machine. In such cases, we recommend starting off with a less aggressive default on multi-cored machines; the value can be increased later if hosting operations begin to back up.
Additional resource types may be configured by defining a key with the format throttle.resource.<resource-name>
. When adding new types, it is strongly recommended to configure their ticket counts explicitly using this approach.
Default value | Description |
---|---|
scaling.concurrency | |
cpu | Allows adjusting the scaling factor used. Various other CPU/throttling dependent properties are defined in terms of this setting, so adjusting this value implicitly adjusts those. Some examples:
The default value, |
throttle.resource.git-lfs | |
80 | Limits the number of Git LFS file transfer operations which may be running concurrently. This is primarily intended to prevent Git LFS requests from consuming all available connections thereby degrading UI and Git hosting operation. This should be a fraction of the maximum number of concurrent connections permitted by Tomcat. |
throttle.resource.git-lfs.timeout | |
0 | Controls how long threads will wait for Git LFS uploads/downloads to complete when the system is already running the maximum number of concurrent transfers. It is recommended this be set to zero (i.e. don't block) or a few seconds at most. Since waiters still hold a connection, a non-zero wait time defeats the purpose of this throttle. This value is in seconds. |
throttle.resource.scm-command | |
25 | Limits the number of SCM commands, such as: |
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. This value is in seconds. |
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. This value is in seconds. |
throttle.resource.scm-hosting.strategy | |
adaptive | Specifies the strategy for throttling SCM hosting operations. Possible values are 'adaptive' and 'fixed'. If 'fixed' is specified, throttle.resource.scm-hosting.fixed.limit is used as the fixed upper limit on the number of concurrent hosting operations. If 'adaptive' is specified, the maximum number of hosting operations will vary between throttle.resource.scm-hosting.adaptive.min and throttle.resource.scm-hosting.adaptive.max based on how many hosting operations the system believes the machine can support in its current state and given past performance. If any configured adaptive throttling setting is invalid and reverts to a default but this conflicts with other correctly configured or default settings, the throttling strategy will revert to 'fixed'. E.g. this will occur if |
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. Setting a lower limit provides a way to specify a minimum service level for SCM hosting operations regardless of what the adaptive throttling heuristic believes the machine can handle. There is limited support for mathematical expressions; +,-,*,/ and () are supported. |
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. Note that if the machine does not have sufficient memory to support this default value or an explicitly configured value, a smaller value will be chosen on startup. Adaptive throttling will vary the total tickets There is limited support for mathematical expressions; +,-,*,/ and () are supported. |
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 value represents a trade-off: higher numbers may boost raw throughput of hosting operations, but at the expense of overall system responsiveness for all users. Increasing the target too high or too low brings diminishing returns. 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. |
SCM - Cache
See Scaling for Continuous Integration performance for more information about configuring the SCM Cache.
Note: The settings controlled by these properties can be configured via REST. The REST configuration takes precedence over the configuration in bitbucket.properties
.
Default value | Description |
---|---|
plugin.bitbucket-scm-cache.expiry.check.interval | |
30 | Controls how frequently expired cache entries are invalidated and removed from the cache. This 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) This 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) This 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. This value is in bytes. |
plugin.bitbucket-scm-cache.protocols | |
HTTP,SSH | Controls which protocols caching is applied to. The This property value is a comma-separated list. Valid values are: |
plugin.bitbucket-scm-cache.refs.enabled | |
false | Controls whether ref advertisement operations are cached. |
plugin.bitbucket-scm-cache.refs.maxCount | |
1 | The maximum number of ref advertisement entries to retain per repository. If there are more than this configured limit, the least recently accessed entry will be invalidated. Note that for ref advertisements, only one entry will be created. |
plugin.bitbucket-scm-cache.refs.ttl | |
180 | Controls the 'time to live' for ref advertisement caches. This value is in seconds. |
plugin.bitbucket-scm-cache.upload-pack.enabled | |
true | Controls whether caching is enabled for git-upload-pack (clone operations). |
plugin.bitbucket-scm-cache.upload-pack.maxCount | |
20 | The maximum number of upload-pack cache entries to retain per repository. If there are more than this configured limit, the least recently accessed entry will be invalidated. |
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. This value is in seconds. |
SCM - git
Default value | 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, those processes will be forked directly. This eliminates an unnecessary fork (git -> git-http-backend) and may improve scalability. | |
plugin.bitbucket-git.backend.http.buffer.size | |
8192 | 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 | |
4096 | 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:
When using "copy" or "copies", the value may optionally be suffixed with a "+" to use |
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.commandsize | |
32000 | Defines the maximum number of characters that can be added to a single command. Different operating systems (and even different versions of the same operating system) have different hard limitations they apply to command line lengths. 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. This default is based on Windows, which has a limit of 32768 characters. Testing on Linux (Ubuntu 12.04 running a 3.2 kernel) found that its limit is at least 32x the limit imposed by Windows. |
plugin.bitbucket-git.environment.variablesize | |
16000 | 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 behaviour 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-scm-git.ssh.binary | |
ssh | Defines the SSH binary to use for outgoing SSH commands, i.e. git commands that fetch from or push to external repositories over SSH. This setting does not affect incoming SSH requests. |
plugin.bitbucket-git.author.name.type | |
displayname | Defines whether commits created by the system should use the username (jdoe) or the display name (John Doe) to specify the Git author/committer. By default, the display name will be used. This value can be either |
SMTP
Default value | Description |
---|---|
mail.timeout.connect | |
60 | Controls the timeout for establishing an SMTP connection. This value is in seconds. |
mail.timeout.send | |
60 | Controls the timeout for sending an e-mail. This value is in seconds. |
mail.test.timeout.connect | |
30 | Controls the timeout for establishing a test SMTP connection. Shorter timeouts should be applied for when sending test e-mails, as the test occurs in user time. This value is in seconds. |
mail.test.timeout.send | |
30 | Controls the timeout for sending a test e-mail. Shorter timeouts should be applied for when sending test e-mails, as the test occurs in user time. This value is in seconds. |
mail.error.pause.log | |
300 | Controls how frequently messages will go to the standard log file about mail sending errors. All errors are logged to This value is in seconds |
mail.error.pause.retry | |
5 | Controls how long to wait before retrying to send a message if an error occurs. This value is in seconds |
mail.threads | |
1 | Controls the number of threads to use for sending emails. Higher values may result in higher mail server load, but may also allow the system to work through its internal queue faster. |
mail.max.message.size | |
1048576 | Controls the maximum allowed size of a single mail message in bytes, which is the sum of the subject and body sizes. This value is in bytes. |
mail.max.queue.size | |
157286400 | Controls the maximum allowed size for the mail queue in bytes (any new message will be rejected if the mail queue reaches that size) This value is in bytes. |
mail.crypto.protocols | |
SSLv2Hello TLSv1 TLSv1.1 TLSv1.2 | Space-separated list of crypto protocols to use when sending encrypted email. This default value is POODLE-safe. Order does not matter - JavaMail always tries the latest supported protocol first. An empty value causes the product to use all protocols supported by the shipped version of JavaMail which may not be be POODLE-safe |
mail.crypto.ciphers | |
Space-separated list of ciphers to use when connecting via SSL or TLS. An empty value causes the product to use all ciphers supported by the JVM |
SSH command execution
Default value | Description |
---|---|
plugin.ssh.command.timeout.idle | |
7200 | 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 This values is in seconds. |
plugin.ssh.nio.workers | |
9 | Controls the maximum number of NIO worker threads to process incoming SSH commands. Apache MINA uses a default of 9, which is also the default here. |
plugin.ssh.auth.timeout | |
30 | Controls the timeout when trying to authenticate the incoming SSH command. If authentication does not complete within this period the SSH command will fail. Using a shorter timeout hastens the rejection SSH commands under heavy load and can help keep open socket/file count down. This values is in seconds. |
plugin.ssh.session.pending-writes.max | |
3840 | Controls the number of pending writes the throttling mechanism will allow SSH sessions. Throttling works as a flow control mechanism to prevent the system from writing too much data to Apache MINA's WriteRequestQueue. This is particularly helpful when clients (such as TortoiseGit) setup session channels with extremely large window sizes (2GBs) which means Apache MINA's own flow control mechanism will not stop the command from writing data. A default value of 512 means that at any given time the system will only be responsible for, at most, 4 MBs per session (some more data may be written to the queue as part of Apache MINA's own handling of the SSH protocol). Rate limiting will be applied to any SSH session which establishes a channel with a remote window size larger than A value of 0 or less effectively disables session io rate limiting. |
SSH security
Default value | 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: 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: 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: To enable additional macs see the KB article Disable default SSH algorithms. |
Search
Default value | Description |
---|---|
plugin.search.pageSize.primary | |
10 | Controls the page size of primary search results (eg. code for code search) |
plugin.search.pageSize.secondary | |
10 | Controls the page size of secondary search results (eg. sidebar PRs/repos/etc) |
Server
Default value | Description |
---|---|
server.context-path | |
/ | Controls the context path where the application should be published, / by default. |
server.display-name | |
Atlassian Bitbucket | Controls the application's display name. |
server.session.cookie.http-only | |
true | Controls whether the session cookie should include an HttpOnly restriction, for those browsers that honor it. HttpOnly is enabled by default. |
server.session.cookie.name | |
BITBUCKETSESSIONID | Controls the name used for the session cookie, which is "BITBUCKETSESSIONID" by default. Note that most servlet containers use "JSESSIONID" by default. That is not used here to facilitate installations where multiple applications have the same hostname (typically via reverse proxying) with distinct context paths. In such a setup, using "JSESSIONID" can result in unexpected behavior where logging into one application logs users out of others. |
server.session.timeout | |
1800 | Controls the session's timeout, which defaults to 30 minutes. Session timeout may not result in a user having to login again; they may automatically receive a new session via a separate remember-me token. This value is in seconds. |
server.session.tracking-modes | |
cookie | Controls which mechanisms may be used for tracking sessions. By default, only "cookie" tracking is enabled. Other options are "ssl", to use the SSL session ID, and "url", to append the session ID to the URL after a semi-colon. Multiple values may be specified separated by commas (e.g. "cookie,url") |
Server Connectors
These properties control the primary server connector. Additional connectors can be configured using the prefix server.additional-connector.#
, where #
is the connector number. For example: to set a port on the first additional connector, the property would be server.additional-connector.1.port=7991
. Numbers 1 to 5 are supported, allowing for 5 connectors in addition to the primary connector.
Default value | Description |
---|---|
server.address | |
Controls the network address the application will bind to, 0.0.0.0 by default. | |
server.compression.enabled | |
true | Controls whether the server will attempt to compress data to reduce network costs. By default, compression is enabled on all connectors. |
server.compression.excluded-user-agents | |
Controls the list of user-agents to exclude from compression. | |
server.compression.mime-types | |
text/css,text/html,text/javascript,text/json,text/plain,text/xml,text/x-javascript,\ | Controls which MIME types are compressed, when compression is enabled. CSS, HTML, JavaScript and JSON are compressed by default. |
server.compression.min-response-size | |
Controls the minimum response length for the compression to be performed. Only the mime-types specified as part of the This value is in bytes. | |
server.connection-timeout | |
20000 | Controls the connection timeout, which defines how long the server will wait for a request after a connection is established. This value is in milliseconds. |
server.max-http-header-size | |
0 | Controls the maximum size of the HTTP message header. When using the default value (0), Tomcat's default limit is honored. This value is in bytes. |
server.max-http-post-size | |
0 | Maximum size of the HTTP post or put content. When using the default value (0), Tomcat's default limit is honored. This value is in bytes. |
server.port | |
7990 | Controls the port where the application will listen for connections, 7990 by default. |
server.proxy-name | |
The proxy name, used to construct proper redirect URLs when a reverse proxy is in use. | |
server.proxy-port | |
The proxy port, used to construct proper redirect URLs when a reverse proxy is in use. If a proxy port is not set, but a name is, the connector's port will be used as the default. | |
server.redirect-port | |
The redirect port to use when redirecting from non-SSL to SSL. Defaults to 443, the standard SSL port. | |
server.require-ssl | |
false | Require an SSL connection when connecting to the server. Setting this to "true" will automatically redirect insecure connections to the configured "redirect-port" for their connectors. |
server.scheme | |
http | The connector scheme, either "http" or "https". Defaults to "http" unless "secure" is set to "true"; then it defaults to "https". In general, this property should not need to be set. |
server.secure | |
false | Whether the connector is secured. Note that setting this to "true" does not enable SSL; SSL is enabled using |
server.server-header | |
Controls the value to use for the Server response header. If empty, which is the default, no header is sent. | |
server.ssl.ciphers | |
Controls the supported SSL ciphers for the connector. This property value is a comma-separated list. | |
server.ssl.client-auth | |
Controls whether the client authentication is wanted ("want") or needed ("need"), this setting directly relates to the Default is empty, which corresponds to the Tomcat's default value of false. | |
server.ssl.enabled | |
false | Controls whether SSL is enabled. By default, SSL is disabled and the primary connector uses unsecured HTTP. |
server.ssl.key-alias | |
tomcat | Controls the alias used when selecting the key to use in the keystore. For compatibility with keys setup for Bitbucket Server 4.x and earlier, the default is "tomcat". |
server.ssl.key-password | |
changeit | Controls the password used to access the key within the keystore. ( |
server.ssl.key-store | |
${bitbucket.shared.home}/config/ssl-keystore | Controls the location of the keystore, "$BITBUCKET_HOME/shared/config/ssl-keystore" by default. |
server.ssl.key-store-password | |
changeit | Controls the password used to access the keystore. ( |
server.ssl.key-store-type | |
${keystore.type:jks} | Controls the keystore type. The JVM's default keystore type as returned by |
server.ssl.protocol | |
TLS | Controls the SSL protocol to use for the connector. |
server.ssl.trust-store | |
Controls which trust store holds the SSL certificates | |
server.ssl.trust-store-password | |
Controls the password to be used to access the trust store. | |
server.ssl.trust-store-provider | |
Controls the provider for the trust store. | |
server.ssl.trust-store-type | |
Controls the type for the trust store. |
Server busy banners
Default value | 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. This 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. This 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 their values will be used and the Setup Wizard will not display the corresponding configuration screens.
You can use these properties to automate setup and remove the need to interact with the Setup Wizard when provisioning a new server.
See our automated setup documentation for more details.
Default value | Description |
---|---|
setup.displayName | |
Bitbucket | The display name for the instance. |
setup.baseUrl | |
The base URL for the instance. | |
setup.license | |
AAABa1evaA4N... | The license. |
setup.sysadmin.username | |
admin | The username for the system admin account. |
setup.sysadmin.password | |
password | The password for the system admin account. |
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. |
Syntax highlighting
See Configuring syntax highlighting for file extensions for more information.
Default value | Description |
---|---|
syntax.highlighter.<MIME type>.executables | |
exe1,exe2 | Controls the language highlighter used for a given set of hashbang executables. The |
syntax.highlighter.<MIME type>.extensions | |
ext1,ext2 | Controls the language highlighter used for a given set of file extensions. The |
syntax.highlighter.text/x-sh.executables | |
sh,bash,zsh | |
syntax.highlighter.text/x-erlang.executables | |
escript | |
syntax.highlighter.text/javascript.executables | |
node | |
syntax.highlighter.text/x-perl.executables | |
perl | |
syntax.highlighter.text/x-python.executables | |
python | |
syntax.highlighter.text/x-ruby.executables | |
ruby | |
syntax.highlighter.text/x-sh.extensions | |
makefile,Makefile | |
syntax.highlighter.text/velocity.extensions | |
vm | |
syntax.highlighter.text/x-objectivec.extensions | |
m |
Tasks
Default value | Description |
---|---|
task.max.anchors.per.request | |
500 | Maximum number of anchors that can be used when counting or searching tasks |
task.max.contexts.per.request | |
100 | Maximum number of contexts that can be used when counting or searching tasks |
task.max.tasks.per.request | |
500 | Maximum number of tasks that can be retrieved when searching tasks |
task.query.disjunction.size | |
100 | Sets the maximum size of the disjunction clause when querying tasks by anchors or contexts |
Webhooks
See POST service webhook for Bitbucket Server for more information.
Default value | Description |
---|---|
plugin.com.atlassian.stash.plugin.hook.threadPoolCoreSize | |
2 | Core size of thread pool – the default number of concurrent hooks notifications. |
plugin.com.atlassian.stash.plugin.hook.threadPoolMaxSize | |
3 | Maximal size of thread pool – the maximum number of concurrent hooks notifications. |
plugin.com.atlassian.stash.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.stash.plugin.hook.connectionTimeout | |
10000 | Connection timeout for hook request. When the connection times out a warning message will be logged. This value is in milliseconds. |
plugin.com.atlassian.stash.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.stash.plugin.hook.changesLimit | |
100 | Limit of maximum count of changes for a single changeset in the POST data. |
Zero downtime backup/disaster recovery
Default value | Description |
---|---|
disaster.recovery | |
false | When set to true repair jobs are triggered on startup |
integrity.check.pullRequest.batchSize | |
1000 | Maximum number of results returned in each database call used by integrity checking tasks |
integrity.check.pullRequest.updatedSinceDays | |
7 | Controls the date range used to filter merged pull requests for integrity checking. This property defines the number of days to go back since the most recent pull request update |
integrity.check.repository.batchSize | |
1000 | Maximum number of results returned in each database call used by repository check tasks |