Administer Bitbucket in AWS

Still need help?

The Atlassian Community is here for you.

Ask the community

The AWS Quick Start template as a method of deployment is no longer supported by Atlassian. You can still use the template, but we won't maintain or update it.

We recommend deploying your Data Center products on a Kubernetes cluster using our Helm charts for a more efficient and robust infrastructure and operational setup. Learn more about deploying on Kubernetes.

AWS now recommends switching launch configurations, which our AWS Quick Start template uses, to launch templates. We won’t do this switch, however, as we’ve ended our support for the AWS Quick Start template. This means you're no longer able to create launch configurations using this template.

This page describes administering a single-node instance of Bitbucket Server on AWS. For a deployment that is better suited to the architectural principles of AWS, we recommend deploying a clustered Bitbucket Data Center instance, which offers greater performance at scale, high availability and elastic scalability.

This page describes the Atlassian Bitbucket Amazon Machine Image (AMI), what's inside it, how to launch it, and how to perform administration tasks in the Amazon Web Services (AWS) environment.

The Bitbucket AMI

The Atlassian Bitbucket Server AMI provides a typical deployment of Bitbucket Server in AWS. It bundles all the components used in a typical Bitbucket Server deployment (reverse proxy, external database, backup tools, data volume, and temporary storage) pre-configured and ready to launch. 

You can use the Atlassian Bitbucket Server AMI as a "turnkey" deployment of a Bitbucket Server instance in AWS, or use it as the starting point for customizing your own, more complex Bitbucket Server deployments.

On this page:

Components of the Bitbucket Server AMI

An instance launched from the Atlassian Bitbucket Server AMI contains the following components:

  • Bitbucket Server (either the latest version or a version of your choice),
  • an external PostgreSQL database,
  • nginx as a reverse proxy,
  • the Bitbucket Server DIY Backup utilities pre-configured for native AWS snapshots,
  • an EBS Volume and Instance Store to hold the data. 

Operating system

Amazon Linux 64-bit, 2016.09.0

Bitbucket ServerBitbucket Server (latest public version or a version of your choice) is downloaded and installed on launch.
Administrative toolsatlassian-bitbucket-diy-backup pre-installed and configured for AWS native backup, accessible over SSH.
Reverse proxy

nginx, configured as follows:

  • listens on port 80 and (optionally) 443,
  • (optionally) terminates SSL (HTTPS) and passes through plain HTTP to Bitbucket Server,
  • displays a static HTML page when the Bitbucket Server service is not running.
DatabasePostgreSQL 9.3
Block devices
  1. An EBS volume (/dev/xvdf, mounted as /media/atl), that stores:
    • the Bitbucket Server shared home directory, containing all of Bitbucket Server's repository, attachment, and other data,
    • PostgreSQL's data directory.
  2. An EC2 Instance Store (/dev/xvdb, mounted on /media/ephemeral0) to store Bitbucket Server's temporary and cache files. 

Launching your instance

The Atlassian Bitbucket Server AMI can be launched by either

  • using a CloudFormation template which automates creation of the associated Security Group and IAM Role. For more info, see Quick Start with Bitbucket Server and AWS.
  • manually using the AWS Console, which gives finer control over the optional components in the instance and AWS-specific network, security, and block device settings. For more info, see Launch Bitbucket in AWS manually.

On first boot, the Atlassian Bitbucket Server AMI reads the file /etc/atl (if any), which can override variables that enable each of the installed components. So for example to enable a self-signed SSL certificate, you can supply user data to the instance at launch time like this:

#!/bin/bash
echo "ATL_SSL_SELF_CERT_ENABLED=true" >>/etc/atl


The following variables can be configured: 

Variable nameDefault valueDescription
ATL_NGINX_ENABLEDtrueSet to false to disable the Nginx reverse proxy, and leave Bitbucket Server's server.xml configured to listen on port 7990 with no proxy.
ATL_POSTGRES_ENABLEDtrueSet to false to disable the PostgreSQL service, and leave Bitbucket Server configured with its internal H2 database.
ATL_SSL_SELF_CERT_ENABLEDfalse

Set to true to enable a self-signed SSL certificate to be generated at launch time, and for Bitbucket Server's server.xml and Nginx's nginx.conf to be configured for HTTPS.

Requires ATL_NGINX_ENABLED also to be true.

ATL_BITBUCKET_VERSIONlatest

Must be a valid Bitbucket version number (for example, 5.5.0), or latest for the latest public release.

See Proxy and secure Bitbucket for more information about Bitbucket Server's server.xml  configuration file. 

Connecting to your instance using SSH

When connecting to your instance over SSH, use ec2-user as the user name, for example:

ssh -i keyfile.pem ec2-user@ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com

The ec2-user has sudo access. The Atlassian Bitbucket Server AMI does not allow SSH access by root

Installing an SSL certificate in your Bitbucket Server instance

If launched with a self-signed SSL certificate (you selected SSLCertificate > Generate a self-signed certificate in Quick Start with Bitbucket Server and AWS or you set ATL_SSL_SELF_CERT_ENABLED=true in Launch Bitbucket in AWS manually), Bitbucket Server will be configured to force HTTPS and redirect all plain HTTP requests to the equivalent https:// URL.

It's highly recommended to replace this self-signed SSL certificate with a proper one for your domain, obtained from a Certification Authority (CA), at the earliest opportunity. See Secure Bitbucket in AWS. Once you have a true SSL certificate, install it as soon as possible.

To replace the self-signed SSL certificate with a true SSL certificate

  1. Place your certificate file at (for example) /etc/nginx/ssl/my-ssl.crt
  2. Place your password-less certificate key file at /etc/nginx/ssl/my-ssl.key
  3. Edit /etc/nginx/nginx.conf as follows:
    1. Replace references to /etc/nginx/ssl/self-ssl.crt with /etc/nginx/ssl/my-ssl.crt
    2. Replace references to /etc/nginx/ssl/self-ssl.key with /etc/nginx/ssl/my-ssl.key
  4. Append the contents of /etc/nginx/ssl/my-ssl.crt to the default system PKI bundle (/etc/pki/tls/certs/ca-bundle.crt) to ensure scripts on the instance (such as DIY backup) can curl successfully. 
  5. Restart nginx.

Backing up your instance

The Atlassian Bitbucket Server AMI includes a complete set of Bitbucket Server DIY Backup scripts which has been built specifically for AWS. For instructions on how to backup and restore your instance please refer to Using Bitbucket DIY Backup in AWS.

Upgrading your instance

To upgrade to a later version of Bitbucket Server in AWS you first must connect to your instance using SSH, then follow the steps in the Bitbucket Server upgrade guide.

Stopping and starting your EC2 instance

An EC2 instance launched from the Atlassian Bitbucket Server AMI can be stopped and started just as any machine can be powered off and on again.

When stopping your EC2 instance, it is important to first

  1. Stop the atlbitbucket, atlbitbucket_search, and postgresql93 services.
  2. Unmount the /media/atl filesystem.

If your EC2 instance becomes unavailable after stopping and restarting

When starting your EC2 instance back up again, if you rely on Amazon's automatically assigned public IP address (rather than a fixed private IP address or Elastic IP address) to access your instance, your IP address may have changed. When this happens, your instance can become inaccessible and display a "The host name for your Atlassian instance has changed" page. To fix this you need to update the hostname for your Bitbucket Server instance.

To update the hostname for your Bitbucket Server instance

  1. Restart the Bitbucket service on all application nodes by running this command, which will update the hostname

    sudo service atlbitbucket restart
  2. Wait for Bitbucket Server to restart.
  3. If you have also set up Bitbucket Server's Base URL to be the public DNS name or IP address be sure to also update Bitbucket Server's base URL in the administration screen to reflect the change.

Migrating your existing Bitbucket Server or Bitbucket Data Center instance into AWS

Migrating an existing instance to AWS involves moving consistent backups of your ${BITBUCKET_HOME} and your database to the AWS instance.

To migrate your existing instance into AWS

  1. Check for any known migration issues in the Bitbucket Data Center and Server Knowledge Base.
  2. Alert users to the forthcoming service outage.
  3. Create a user in the Bitbucket Server Internal User Directory with SYSADMIN permissions to the instance so you don't get locked out if the new server is unable to connect to your User Directory.
  4. Take a backup of your instance with either the Bitbucket Server Backup Client (Bitbucket Server only) or the Bitbucket Server DIY Backup (Bitbucket Server or Data Center).
  5. Launch Bitbucket Server in AWS using the Quick Start instructions, which uses a CloudFormation template.
  6. Connect to your AWS EC2 instance with SSH and upload the backup file.
  7. Restore the backup with the same tool used to generate it.
  8. If necessary, update the JDBC configuration in the ${BITBUCKET_HOME}/shared/bitbucket.properties file.

Resizing the data volume in your Bitbucket Server instance

By default, the application data volume in an instance launched from the Atlassian Bitbucket Server AMI is a standard Linux ext4 filesystem, and can be resized using the standard Linux command line tools.

To resize the data volume in your Bitbucket Server instance

  1. Stop the atlbitbucketatlbitbucket_search, and postgresql93 services.
  2. Unmount the /media/atl filesystem.
  3. Create a snapshot of the volume to resize.
  4. Create a new volume from the snapshot with the desired size, in the same availability zone as your EC2 instance.
  5. Detach the old volume and attach the newly resized volume as /dev/sdf.
  6. Resize /dev/sdf using resize2fs, verify that its size has changed, and remount it on /media/atl
  7. Start the atlbitbucketatlbitbucket_search, and postgresql93 services.

For more information, see Expanding the Storage Space of an EBS Volume on LinuxExpanding a Linux Partition, and the Linux manual pages for resize2fs and related commands. 

Moving your Bitbucket Server data volume between instances

Occasionally, you may need to move your Bitbucket Server data volume to another instance–for example, when setting up staging or production instances, or when moving to an instance to a different availability zone. 

There are two approaches to move your Bitbucket Server data volume to another instance

  1. Take a backup of your data volume with Bitbucket Server DIY Backup, and restore it on your new instance. See Using Bitbucket DIY Backup in AWS for this option. 
  2. Launch a new instance from the Atlassian Bitbucket Server AMI with a snapshot of your existing data volume.

    A Bitbucket Server data volume may only be moved to a Bitbucket Server instance of the same or higher version than the original.

To launch a new instance from the Bitbucket Server AMI using a snapshot of your existing Bitbucket Server data volume

  1. Stop the atlbitbucketatlbitbucket_search, and postgresql93 services on your existing Bitbucket Server instance.
  2. Unmount the /media/atl filesystem.
  3. Create a snapshot of the Bitbucket Server data volume (the one attached to the instance as /dev/sdf).
  4. Once the snapshot generation has completed, launch a new instance from the Atlassian Bitbucket Server AMI as described in Launch Bitbucket in AWS manually. When adding storage, change the EBS volume device to /dev/sdf  as seen below and enter the id of the created snapshot.
  5. If the host name (private or public) that users use to reach your Bitbucket Server instance has changed as a result of moving availability zones (or as a result of stopping an instance and starting a new one) you will need to SSH in and run
    sudo /opt/atlassian/bin/atl-update-host-name.sh <newhostname>
    where <newhostname> is the new host name. 
  6. Once Bitbucket Server has restarted your new instance should be fully available. 
  7. If the host name has changed you should also update the JDBC URL configuration in the bitbucket.properties file (typically located in /var/atlassian/application-data/bitbucket/shared/), as well as Bitbucket Server's base URL in the administration screen to reflect this.
Last modified on May 30, 2023

Was this helpful?

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