--- Title: Plans & Pricing Url: https://support.deploybot.com/account-billing/plans-pricing --- To sign up for a DeployBot account, please visit our [sign-up page](https://deploybot.com?utm_source=support-site). If you’re a current DeployBot customer, you can change your account at any time from the Plans & Billing section in your account. DeployBot has 2 base pricing tiers: **Plus Plan** * Price: $29/month * Connect up to 20 repositories * Unlimited deployments * 10 users **Premium Plan** * Price: $59/month * Connect up to 50 repositories * Unlimited deployments * Priority Deployments * 100 users **Interested in upgrading to plan with more than 50 repositories?** [Contact our Success team](https://www.deployhq.com/contact) to upgrade to the plans below **Platinum (75)** * Price: $75/month * Connect up to 75 repositories * Unlimited deployments * Priority Deployments * Unlimited users **Platinum (100)** * Price: $100/month * Connect up to 100 repositories * Unlimited deployments * Priority Deployments * Unlimited users **Platinum (150)** * Price: $150/month * Connect up to 150 repositories * Unlimited deployments * Priority Deployments * Unlimited users **Platinum (200)** * Price: $200/month * Connect up to 200 repositories * Unlimited deployments * Priority Deployments * Unlimited users **All plans include:** * Unlimited build minutes * Email support These prices will be valid starting on the 1st of May 2024. If you prefer annual payments, please follow the instructions provided in this [help article](//support.deploybot.com/article/49-do-you-offer-annual- payments). ### Do you have a discount for non-profits or students? We do provide such discounts, please ask to the support team. --- Title: Do you offer annual payments? Url: https://support.deploybot.com/account-billing/do-you-offer-annual-payments --- Yes! We offer the ability to pay in advance for DeployBot by adding a balance to your account. Buy 12 months in advance and we'll add the 13th month for free, just email us (support@deploybot.com) once you've added your credits to take advantage of this offer. To pay in advance, login to your DeployBot account as the account owner. Click on the " **Account** option in the top right, and then select **Plans & Billings**. On the `Plans & Billing` page there will be an option on the right that mentions `Pay in advance` where you should click on the `Make a one-time payment `hyperlink. You'll then have the ability to add a balance to your account. After you click the **Make Payment** button we will charge the card on file. The amount will then be added to your account balance. To change your card of file [check out our help doc on the topic](//support.deploybot.com/article/73-how-do-i-change- the-credit-card-on-my-account). On your next billing date, we will withdraw the amount from your account balance instead of your credit card. Your invoice will reflect this information both in the email and in the invoice in your account. In the past invoices section, you can see if you made a payment from your credit card or account balance. You can also view invoices for advance payments. Payments made in advance are non-refundable. If you cancel your account the balance will not be refunded. **Please note:** If you don't have enough credits in your current account balance, we will charge your credit card for the difference. Only account owners can add an account balance. Credits purchased in advance are non- refundable. We recommend testing to confirm that DeployBot will meet all of your Deployment needs _before_ purchasing credits in advance. --- Title: How can I cancel my account? Url: https://support.deploybot.com/account-billing/how-can-i-cancel-my-account --- You can cancel your account at any time for no penalty. If you would like to cancel your account for any reason, this can be done under the Account tab (top right corner of the page). Then go to the “Plans & Billing” tab, scroll to the “Frequently Asked Questions” box and click the “cancel your account” link. **Please note:** This option is only available for the account owner and will result in a deletion of all your data. --- Title: How do I get email notifications about deployments? Url: https://support.deploybot.com/account-billing/how-do-i-get-email-notifications-about-deployments --- DeployBot can email you when a deployment succeeds so you know it was completed and what was deployed. An email notification will also go out if the deployment failed for any reason (and why), as well as if it was skipped. Email notifications for a successful deployment will show you the deployed revision range, who deployed the changes, and link to the environment where the deployment occurred. To disable email notifications for deployments, begin by clicking on your name in the top right corner of the dashboard. Then, navigate to the "email notifications" tab located at the top of the page. From there, choose the repositories for which you wish to halt the receipt of notifications. **Account admin or owners within DeployBot will consistently receive notifications.** --- Title: Can I change my account owner? Url: https://support.deploybot.com/account-billing/can-i-change-my-account-owner --- The account owner is the only user who can delete repositories and change plans and billing. If required, the current account owner can make another user the new owner. Log in, then click on the "Account" tab. In this section, you will see a dropdown where you can make the change. Select the new owner from the dropdown, then click Save changes. Keep in mind that once the change is made you will no longer be the account owner. --- Title: How do I change the credit card on my account? Url: https://support.deploybot.com/account-billing/how-do-i-change-the-credit-card-on-my-account --- DeployBot allows you to update your credit card information should you need to. To change your credit card, log into your DeployBot account. Click on the "Account” option in the top right, and then select “Plans & Billing”. On the “Plans & Billing” page there will be an option on the right that mentions your upcoming charge and says "... _ending in XXXX_ ”. **Please note:** this is only available to account owners Click on the hyperlink and you will be able to change your card information on the next screen. --- Title: Where can I find a receipt? Url: https://support.deploybot.com/account-billing/where-can-i-find-a-receipt --- Receipts are available to account owners only. They can be found under the `Account` tab under `Plans & Billing`. An email receipt is also sent to the account owner each month. --- Title: How can I change my account URL? Url: https://support.deploybot.com/account-billing/how-can-i-change-my-account-url --- It is possible to change the sub-domain of your DeployBot account. To change the sub-domain, log in as the Account Owner and click on `Account` in the top right. From the account page, you will find an option to edit your sub-domain. Click on the `Do you want to change this URL?` hyperlink. You will then be able to type in your desired new sub-domain. Click on `Update the URL` and your sub-domain will be updated. ### Before you change the domain, please keep in mind: * Changing your account URL affects API clients and webhooks that refresh the repositories on our side. * The change is immediate. Please make sure to update bookmarks and notify users that need to log into your account to be aware of the change. * Please make sure to update the webhooks in your GitHub/Bitbucket account to use the new URL. --- Title: Do you accept Paypal? Url: https://support.deploybot.com/account-billing/do-you-accept-paypal --- We only accept credit card payments through `MasterCard`, `Visa`, and `American Express`. **Do you have a PayPal account?** If so, you may want to consider the [PayPal Plus Credit Card](https://www.paypal.com/cgi- bin/webscr?cmd=xpt/Marketing/general/PPPlusCC-outside), which will allow you to make MasterCard purchases with your PayPal account. --- Title: Can I change the email address for receipts? Url: https://support.deploybot.com/account-billing/can-i-change-the-email-address-for-receipts --- In some cases, the email address that receives receipts may need to be different from the account owner. By default, this email address is set as the Account Owner's email, but you can change this. To change the receipt email address, the Account Owner can go to `Account` → `Plans & Billing`. From there, update the receipt email address in the 'Receipts' section. From that point forward all receipt emails will be sent to the new address. Also, keep in mind that you can configure more than one email address, configuring them using a comma, like: `dbot@dploy.io,admin@dploy.io`. --- Title: How do I customize my receipt? Url: https://support.deploybot.com/account-billing/how-do-i-customize-my-receipt --- To add custom fields to your receipts such as your Company's name, Address, or Tax IDs, go to **Account > Plans & Billing**. On the 'Receipts' section, click the __customizing the "Bill To" field__ __hyperlink where you will be directed to the 'Receipt Information' page and any information added there will now be included in the "Bill To" field on your receipt. --- Title: DeployBot and DeployHQ Merge FAQ Url: https://support.deploybot.com/account-billing/deploybot-and-deployhq-merge-faq --- ### Why is this merger happening? DeployBot and DeployHQ are joining forces to bring you a better deployment experience! By combining their strengths, you'll have access to a wider range of features and a more powerful deployment toolkit. ### What are the benefits of this merger? * **More Features:** You'll gain access to the combined set of features from both DeployBot and DeployHQ, giving you more flexibility and control over your deployments. * **Enhanced Deployment Environment:** The merger aims to create a more robust and efficient deployment environment for your projects. ### Will my DeployBot account be affected? No, your DeployBot account will remain active. You won't need to take any immediate actions to keep using your account. As the integration progresses, you'll gain access to the new features from DeployHQ. ### What will change? Over time, the two platforms will be merged into a single, unified solution. This may involve changes to the user interface and feature sets. However, you'll be informed well in advance of any significant changes. ### What won't change? Your current DeployBot deployments and workflows will continue to function as usual. The core functionalities of both platforms will be maintained throughout the integration process. ### Will I need to migrate my projects from DeployBot to DeployHQ? To ensure continued support and access to the latest features, we strongly recommend migrating from **DeployBot** to **DeployHQ**. DeployHQ offers a modern, reliable platform with enhanced deployment options designed to improve your development workflow. Need Help Migrating? * A step-by-step [migration guide](https://www.deployhq.com/support/faq/migrating-from-deploybot-to-deployhq) is available on the DeployHQ website to walk you through the process. * Our support team is ready to answer any questions or troubleshoot any issues you encounter. ### Will there be a new pricing structure? The pricing structure hasn't been announced yet. The merged company will likely communicate a new pricing plan or any adjustments to existing plans in due course. ### What will happen to DeployBot accounts? Similar to DeployHQ accounts, DeployBot accounts are expected to remain active. The eventual goal is likely to unify accounts under a single platform. ### Will there be any downtime during the merger? The companies will strive to minimize disruption during the integration process. Ideally, there shouldn't be any significant downtime affecting your deployments. ### Where can I learn more? We recommend staying tuned for further announcements and updates from the merged company. They'll likely provide more information about the specific timeline and details of the integration process. --- Title: Enable Multi-factor Authentication (MFA) Url: https://support.deploybot.com/security/deployment-integrations/users-access/enable-multi-factor-authentication-mfa --- Multi-factor Authentication (MFA) is a security system that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction. This method can involve something you know (like a password), something you possess (like a smart card), and something you are (like fingerprint or facial recognition). By employing MFA, you add an extra layer of protection to your DeployBot account, which helps prevent unauthorised access. It ensures that even if your password is compromised, attackers cannot gain access without the additional authentication factor. In the ever-evolving landscape of cybersecurity threats, MFA stands as a strong line of defense. Thus, enabling MFA on your DeployBot account is a good option to enhance your account security and maintain the integrity of your deployment processes. ## Enable Multi-factor Authentication in your account First step would be to enable it all over your account, in the security tab: ## Configure Multi-factor Authentication for each account Once Multi-factor (MFA) it's enabled in the account, another menu option on the Profile sidebar will appear, called **Multi-factor Authentication**. We should click on Enable Multi-factor Atuhentication to start the flow: Then, we would be able to setup our app of preference for Multi-factor Authentication, such as [Google Authenticator](https://support.google.com/accounts/answer/1066447?hl-en), Microsoft Authenticator, [1Password](https://1password.com/), among others. Once the Authenticator App it's setup, we should introduce the Verification Code, and then, MFA will be enabled in our account. Next time that we are asked for the login, besides the password, we will be asked for the authentication code as well. --- Title: Why developers should use npm ci instead of npm install and its benefits Url: https://support.deploybot.com/build-tools/why-developers-should-use-npm-ci-instead-of-npm-install-and-its-benefits --- As a developer, you may already be familiar with using `npm install` to install dependencies for your Node.js projects. However, there's another command you should consider using: `npm ci` . In this article, we'll explain why developers should use `npm ci` instead of `npm install` and its benefits. ## What is `npm ci` ? Oficial docs: `npm ci` is a command that stands for "clean install." Unlike `npm install` , which can install packages from the `node_modules` cache, `npm ci` installs packages from the `package-lock.json` file. This means that `npm ci` always installs a project with a clean slate, ensuring that you have the exact dependencies and versions listed in the `package-lock.json` file. ## Why use `npm ci` ? Here are a few reasons why developers should use `npm ci` instead of `npm install` : 1. Consistency: `npm ci` ensures that all developers working on a project have the same exact dependencies and versions installed. This helps to eliminate inconsistencies in the development environment, making it easier to reproduce and debug issues. 2. Speed: Since `npm ci` always installs packages from the `package-lock.json` file, it doesn't need to check the `node_modules` cache. This means that `npm ci` can be much faster than `npm install` , especially for large projects with many dependencies. 3. Predictability: `npm ci` installs packages exactly as they are listed in the `package-lock.json` file, without any additional updates or modifications. This ensures that you always have a predictable and stable development environment, without unexpected changes in dependency versions. 4. Automation: `npm ci` is designed to be used in automated environments such as continuous integration and deployment pipelines. By using `npm ci` , you can ensure that your project is always built with a consistent and predictable set of dependencies, regardless of the environment. ## How to use `npm ci` ? To use `npm ci` , simply run the following command in your project directory: ``` npm ci ``` This will install all of the dependencies listed in the `package-lock.json` file, ensuring a clean and consistent installation. ## Conclusion In conclusion, `npm ci` is a command that developers should consider using instead of `npm install` for their Node.js projects. It provides consistency, speed, predictability, and automation benefits, making it a valuable tool for any development team. So, if you haven't already, give `npm ci` a try and see how it can improve your workflow. More info [here](https://deploybot.com/blog/streamline-your-development- workflow-with-npm-and-npm-ci-in-deploybot). --- Title: Setting up and using Build Tools Url: https://support.deploybot.com/build-tools/setting-up-and-using-build-tools --- DeployBot Build Tools are a way to prepare your source code for deployment. You can provide us with a script or a single command that needs to be run, and we will execute it on our servers, inside a protected Docker container, with your source code attached to it. It is a great way to compile or minimize your assets, build your executable files, run tests or a linter on your code, and many other things. ## How does it work? * We create a container, selected by you from our predefined containers or from the official Docker registry. * We execute your build script in that container as part of the deployment process. We also attach a version of the source code that you're deploying to that container. * If the build is successful, any files and directories that are changed/added/removed during the build will be deployed to your server, along with the regular changes introduced by your commits. * If the last command of the build was a failure (had non-zero exit code), the deployment will stop and will be marked as failed. ## Setting up In order to get up and running, you don't need much. In your deployment server settings, you will be able to select one of the [predefined containers](//support.deploybot.com/article/62-docker-containers) \- they are usually a good fit for most purposes. You can find the Build Tools block on your server settings page, in the 'Compile, compress, or minimize your code' section: After the container is selected, you just need to put in your build commands. For example, your grunt commands or your rake commands. These commands will be executed as a script in our container. Your source code will be available in the /source directory - this is the default directory for your build script. Any files written to the /source directory will be deployed to your server. ## Managing dependencies Sometimes your build script needs to install certain dependencies in order to be executed. You can do that right in the build script field, but that means every time your code is deployed the dependencies will be installed again, making the build slower. A better option is to use **Cached build commands** option in advanced settings. Any script placed in this field will be executed only when the following files changed in your repository: _Gemfile, Gemfile.lock, package.json, gulpfile.js, Gruntfile.js, project.clj, composer.json_. You can also specify what particular file change you want to trigger re-caching of build commands by adding this as the first line of your script: `# refresh: myfile.js, test.ini` It could look like this: The following consideration can be made for handling dependencies: 1. When possible, do not store dependencies in your repo. Use .gitignore. 2. If they are required, use the cached build commands option above to ensure DeployBot only includes dependencies when a related file is updated. 3. If your build produces some undesired artifacts (such as node_modules directory containing your dependencies), you need to exclude it from the upload. Use the exclude option in your release server settings in the "exclude certain paths from being uploaded" section. ## Configuring your own containers Sometimes you need to perform some elaborate configuration that you don't want to repeat for every server, for convenience reasons – like build time or configuration time. In this case, you can create your own containers, based on our predefined containers or **any public containers** from [Docker registry](https://registry.hub.docker.com/). To do so, go into **Containers** tab in your account settings and create a new container: After the container is created, you should be able to use it for all the servers in your account. This can save you considerable time during configuration and your builds. Also, if you want to some really advanced container configuration, like using a different Linux version or you have some exotic software requirements, you can build the container on your own and deploy it to the Docker registry first, and then create a new container using it as described here. --- Title: What are build tools and why use them? Url: https://support.deploybot.com/build-tools/what-are-build-tools-and-why-use-them --- Build automation is the act of scripting or automating a wide variety of tasks that software developers do in their day to day activities such as: * compiling program source code into binary code * packaging a compiled program for distribution * running automated tests * deploying to production systems * generating documentation and/or release notes. As a software developer, there are dozens of common tasks that need to be repeatedly completed within a project, for example: * Concatenating and minifying scripts * Preprocessing CSS * Optimizing images * Running tests * Invalidating caches * Moving files around All of these actions can become tedious if done by hand repeatedly. With a build tool, you can spend a small amount of time automating these sort of tasks. This will help you to focus on the development of your website or app going forward. For information on other use cases for build tools, you can view the reference [here](http://www.lihaoyi.com/post/WhatsinaBuildTool.html#use-cases-for-build- tools). ## Types of build tools There are many different types of build tools, To keep things simple, we’ll focus on Grunt and Gulp in this article. But here are a few examples of other build tools you could use: * Broccoli- * Brunch- * npm scripts * Make Each of these has its own unique benefits and syntax but ultimately they can be used to achieve the same goal of automating a repetitive front end task. With so many tools to select from, how do you know which one to select? Here are a few things to look for when selecting a build tool. 1. **Speed.** Ideally, you want your build tool to be fast in execution as there’s much need for speed when iterating on a website or app. Also, when changing a line of code, you want to reload the page to see the changes instantly. Disrupting that process could slow down productivity. 1. **Community driven.** The tool you select should have a healthy community of developers that exchange plugins and are continually adding functionality to support it. 1. **Modular and flexible.** Even the most advanced tool has its limits. Tools that are extensible allow you to add your own custom functionality giving you the flexiblity to adjust as you see fit. Both Grunt and Gulp are fast, backed by strong communities of enthusiasts, modular, and flexible. ## Grunt * A configuration based task runner based on node.js * Tasks live in Gruntfile.js * Tasks are based on Grunt plugins(gruntjs/plugins) ## **Gulp** * Code over configuration syntax * Tasks live in gulpfile.js * Ability to use Gulp plugins and some Node.js packages. Both tools are task runners that use [Node.js](https://nodejs.org/en/), which is an open-source Javascript runtime environment used to develop tools and applications. Grunt and Gulp both also use plugins to accomplish whatever tasks you need them to automate for you. Grunt and Gulp also use the extension .js files to build tasks. For Grunt, you use a Gruntfile.js and for Gulp, you use Gulpfile.js. You can also define flows with grunt.task and gulp.task instead of using functions. ## How do Grunt and Gulp differ? Grunt fulfills many of the requirements above. It has a strong community and a healthy plugin ecosystem. On the other hand, Gulp is built for speed and can execute tasks in parallel. Additionally, Gulp uses code over configuration. This means you can write Javascript to extend or modify tasks that don’t work for you. This is also true for Grunt, but Gulp makes it a bit easier. With that said, there are two main differences between Grunt and Gulp. 1. Grunt uses declarative configuration schema, while Gulp allows you to code your build scripts using JavaScript. 1. Grunt was created around a set of [built-in, and commonly used tasks](https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4), while Gulp is flexible(sound familiar?) and enforces nothing except how the community developed micro-tasks should interact with each other. It’s important to note you can create plugins with Grunt as well. But here’s how the two differ. Grunt uses plugins that often **accomplish multiple tasks at the same time**. This means that the plugin creation process is very different depending on which tool you’re using. Grunt currently has 6,283 community plugins. Gulp has been designed to use a **series of plugins** that each do a task. Each plugin for Gulp is written with the goal of doing one thing very well. As of today(October 2017) the Gulp plugin registry contains 3,328 different plugins for unique purposes. ## Getting started with Grunt Here are a few guides and tutorials that will help you get started with Grunt: * [Getting started- Grunt: The Javascript task runner](https://gruntjs.com/getting-started) * [Getting started with Grunt.js](https://semaphoreci.com/community/tutorials/getting-started-with-grunt-js) * [Getting started with Grunt and Sass](https://www.taniarascia.com/getting-started-with-grunt-and-sass/) ## Getting started with Gulp * [Getting started with Gulp](https://github.com/gulpjs/gulp/blob/master/docs/getting-started.md) * [Setting up and installing Gulp](https://markgoodyear.com/2014/01/getting-started-with-gulp/) After you’ve installed your build tools, now you can include DeployBot in your workflow. The next article discusses [setting up and using build tools](//support.deploybot.com/article/791-setting-up-and-using-build-tools) in DeployBot. --- Title: Docker Containers Url: https://support.deploybot.com/build-tools/docker-containers --- DeployBot has three default Docker containers available for deployments. The containers have the following bases installed * Ubuntu 16.04 * Ubuntu 14.04 * Ubuntu 18.04 * Ubuntu 20.04 ## Ubuntu 20.04 (default) **Base:** * Ubuntu 20.04 **Languages:** * PHP 8.0 * Ruby 3.2.2 * Python 3 * Java 8/11 * Go 1.18 **Development Packages:** * Git 2.17.1 * Subversion 1.9.7 * Mercurial 4.5.3 * cURL 7.58.0 * Wget 1.19.4 * Composer 2.3.5 * RVM 1.29.12 * Node.js 16 * NPM 6.4.1 * Yarn 1.22.18 * Webpack 5.58.1 * Grunt 1.3.2 * Gulp 2.2.0 * Sass 3.7.4 * Bower 1.8.14 * Maven 3.6.3 **Databases:** * MySQL 5.7.26 * PostgreSQL 10.8 * MongoDB 3.6.3 * SQLite 2.8.17 * Redis 4.0.9 ## Ubuntu 18.04 **Base:** * Ubuntu 18.04 **Languages:** * PHP 7.2.17 * Ruby 2.6.3 * Python 2.7.15 * Java 8/11 * Go 1.10.4 **Development Packages:** * Git 2.17.1 * Subversion 1.9.7 * Mercurial 4.5.3 * cURL 7.58.0 * Wget 1.19.4 * Composer 1.8.5 * RVM 1.29.8 * Node.js 10.15.3 * NPM 6.4.1 * Yarn 1.16.0 * Grunt 1.3.2 * Gulp 2.2.0 * Sass 3.7.4 * Bower 1.8.8 * Maven 3.6.0 **Databases:** * MySQL 5.7.26 * PostgreSQL 10.8 * MongoDB 3.6.3 * SQLite 2.8.17 * Redis 4.0.9 ## Ubuntu 16.04 **Base:** * Ubuntu 16.04 **Languages:** * PHP 7.0 * Ruby 2.3 * Python 2.7.12 * Java 7/8 * Go 1.6.2 **Development Packages:** * Git 2.7.4 * Subversion 1.9.3 * Mercurial 3.7.3 * cURL 7.47.0 * Wget 1.17.1 * Composer 1.2.4 * RVM 1.27.0 * Node.js 6.9.2 * Grunt 1.0.0 * Gulp 3.9.1 * Sass 3.4.23 * Bower 1.8.0 * Maven 3.3.9 **Databases:** * MySQL 5.7.16 * PostgreSQL 9.5.5 * MongoDB 2.6.10 * SQLite 2.8.17 * Redis 3.0.6 ## Ubuntu 14.04.2 (Deprecated) **Base:** * Ubuntu 14.04.2 **Languages:** * PHP 5.5.9 * Ruby 2.2.1p85 (default) * Ruby 2.0.0p643 (use as ruby-2.0 in rvm) * Ruby 1.8.7 (use as ruby 1.8 in rvm) * Python 2.7.6 (default, or use as python2 or python2.7) * Python 3.4.0 (use as python3 or python3.4) * Java 1.8.0_45 * Java 1.7.0_80 * Go 1.2.1 **Development Packages:** * Git 1.9.1 * Subversion 1.8.8 * Mercurial 2.8.2 * cURL 7.35.0 * Wget 1.15 * Composer 1.0-dev * RVM 1.26.11 * Node.js 0.12.4 * Grunt (grunt-cli) 0.1.13 * Gulp 3.9.0 * Saas 3.4.14 * Bower 1.4.1 * Maven 3.0.5 **Databases:** * MySQL 5.5.43 * PostgreSQL 9.3.9 * MongoDB 2.4.9 * SQLite 2.8.14 * Redis 2.8.4 --- Title: Common questions about build tools Url: https://support.deploybot.com/build-tools/common-questions-about-build-tools --- ## Table of Contents: * My image is not being updated. Is it possible that you are not pulling the image from docker hub, every time you run the container? * I reviewed the deployment logs but it just says that my commands can’t be found. What am I doing wrong? * How can I find the Docker image or dockerfile for the container Deploybot is using? * Is there an option where I can run DeployBot’s docker container on my server? * DeployBot’s container doesn’t contain the packages I need. What can I do? * Does DeployBot support Git LFS? * Why does DeployBot run the“cache build commands” when files such as composer.json, package.json, etc haven’t been changed? ### My image is not being updated. Is it possible that you are not pulling the image from docker hub, every time you run the container? In most cases, DeployBot doesn’t pull the image from docker hub each time. We try to do it as rarely as possible to allow for reproducible builds and keep deployment times predictable. If you want to have more control over the used image version, you can employ tags and specify them explicitly in the container name(i.e. ubuntu/ubuntu:14.04). If a container name changes, it will be downloaded again. ### I reviewed the deployment logs but it just says that my commands can’t be found. What am I doing wrong? It could be that the programs your running are not installed on our container. You can see what’s included in our container [here](//support.deploybot.com/article/809-docker-containers). If what you’re running is not in our container by default, you’ll need to install them first before you can move forward. Please keep in mind you’re allowed to have full root access inside the container. ### How can I find the Docker image or dockerfile for the container Deploybot is using? Our containers are public and you can find them in the links provided below: * [Ubuntu 14.04 & Ubuntu 16.04](https://hub.docker.com/r/dsabanin/deploybot-containers/tags/) * [Ubuntu 18.04](https://hub.docker.com/r/deploybothq/default-images/tags) We don't have any specific requirements for the container other than that it needs to have bash installed. ### Is there an option where I can run DeployBot’s docker container on my server? We don't have a feature to run our Docker containers on your servers. But we do offer shell deployments where you could connect to your server and run your commands directly there if you want to run the deployment on your server. We have a [blog post](https://deploybot.com/blog/deployments-with-shell-commands- just-got-a-lot-better) and a help article that discusses how to run shell deployments. ### DeployBot’s container doesn’t contain the packages I need. What can I do? What you can do in these situations is to create your own Docker container to use in DeployBot. Our help article on [build tools](//support.deploybot.com/article/791-setting-up-and-using-build-tools) includes instructions on that in the“Configuring your own containers” section on your server settings page. ### Does DeployBot support Git LFS? Unfortunately, we do not yet support LFS by default. But it is possible to use Git LFS right now by using build tools. Inside the container, you are free to install the LFS plugin and set things up yourself. You could also [use a command to install the LFS distribution](https://help.github.com/articles/installing-git-large-file- storage/). ### Why does DeployBot run the“cache build commands” when files such as composer.json, package.json, etc haven’t been changed? We have multiple servers in our deployment cluster and each of them needs to have your pre-built container cached. When your deployment hits a server that it never ran on before, it will trigger"cache build commands" script. We try to catch this before it happens and only execute your deployment on servers that you’ve deployed to already, but it's not always possible. If this is happening frequently, please reach out to our support team so that we can investigate. --- Title: Your cache folder contains root-owned files Url: https://support.deploybot.com/build-tools/your-cache-folder-contains-root-owned-files --- If you encounter the following message in your build log: ``` npm ERR! code EACCES npm ERR! syscall link npm ERR! path /data/data/com.termux/files/home/.npm/_cacache/tmp/ca13ccc3 npm ERR! dest /data/data/com.termux/files/home/.npm/_cacache/content-v2/sha512/43/a6/c7e13485e371db122c19f97a126c3d3a05e3f3050a79998bac598ab110422ff6ca2d65f0907caa47c66eb551785374e9216de04eae820a0f45c2c0cdd376 npm ERR! errno EACCES npm ERR! npm ERR! Your cache folder contains root-owned files, due to a bug in npm ERR! previous versions of npm which has since been addressed. npm ERR! npm ERR! To permanently fix this problem, please run: npm ERR! sudo chown -R 10272:10272 "/data/data/com.termux/files/home/.npm" ``` It means that some cache files in the repository contains wrong permissions and because of that the build pipeline is failing. In order to solve it, something like this should be added before executing the build command: `export npm_config_cache=/.` Which changes the cache directory, et voila, problem solved. --- Title: Using Jekyll with DeployBot Url: https://support.deploybot.com/build-tools/using-jekyll-with-deploybot --- DeployBot’s default Docker container and build tools make it possible to build and deploy Jekyll sites. This allows the __site_ directory to stay out of your repository (in .gitignore). The site's assets build during the deployment. As a note, these instructions include using [Bundler](http://bundler.io/), a dependency manager for Ruby. First, you install Jekyll and Bundler in DeployBot’s container with these build steps: `gem install bundler jekyll` Next, install Bundler: `bundle install` Then build the Jekyll site: `jekyll build` The commands in DeployBot: DeployBot will then build a Jekyll site, outputting the site to the __site_ directory and deploy the contents of your repository to your server. Want to keep the Jekyll `_config-file.yml` file out of your repository? Use DeployBot’s [configuration files](https://deploybot.com/blog/store-and-deploy- configuration-files-through-deploybot) to use the file during deployment. If you'd like DeployBot to compile your site, but only deploy the __site_ directory that's possible. In the Advanced deployment options, set Source to __site_. --- Title: Solving node script deprecation warning Url: https://support.deploybot.com/build-tools/solving-node-script-deprecation-warning --- If you encounter the following message in your build log: ``` SCRIPT DEPRECATION WARNING This script, located at https://deb.nodesource.com/setup_X, used to install Node.js is deprecated now and will eventually be made inactive. Please visit the NodeSource distributions Github and follow the instructions to migrate your repo. https://github.com/nodesource/distributions The NodeSource Node.js Linux distributions GitHub repository contains information about which versions of Node.js and which Linux distributions are supported and how to install it. https://github.com/nodesource/distributions SCRIPT DEPRECATION WARNING ``` The reason behind this is the modified installation process for Node on Ubuntu. The updated container images for this purpose are as follows: * **Ubuntu 20.04 - Node 16 (LTS)** * **Ubuntu 20.04 - Node 18 (LTS)** * **Ubuntu 20.04 - Node 20 (LTS)** You can locate these either in the containers tab or directly in the server settings. Should you face any problems, please do not hesitate to contact us at [support@deploybot.com](mailto:support@deploybot.com). --- Title: The build container runs out of memory Url: https://support.deploybot.com/build-tools/the-build-container-runs-out-of-memory --- ### What is a Build Container? Before we dive into the solutions, let's first understand what a build container is. A build container is a lightweight, portable container that is used to build and compile code. Build containers can help to ensure that your builds are consistent and reproducible, regardless of the environment they are run in. Build containers typically run on top of a containerization platform like Docker. They provide an isolated environment for running build processes, which can help to avoid conflicts with other software on your system. ### What Causes a Build Container to Run Out of Memory? A build container can run out of memory for a variety of reasons. Some of the most common causes include: * The build process requires more memory than is available in the container. * The build process is poorly optimised and uses more memory than necessary. * The container is configured with too little memory. * Other processes running on the host machine are consuming too much memory, leaving less available for the container. ### What to Do When a Build Container Runs Out of Memory? If you experience an issue where your build container runs out of memory, there are a few things you can try to resolve the issue. 1. **Increase the Memory Limit** The first thing you should try is to increase the memory limit for the container. You can do this by updating the container's configuration file and specifying a higher memory limit. ``` set -eexport NODE_OPTIONS="--max-old-space-size=4096" # Increases to 4 GB ``` This command sets the memory limit to 4GB. You can adjust the value as needed for your specific use case. 2. **Optimize Your Build Process** If increasing the memory limit doesn't resolve the issue, the next step is to optimize your build process. There are a variety of ways you can do this, depending on the specific issues you are encountering. Some common optimisations include: * Breaking up large builds into smaller, more manageable pieces. * Using caching mechanisms to avoid re-compiling code that hasn't changed. * Reducing the number of dependencies required for the build process. * Simplifying the build process to use fewer resources. By optimising your build process, you can reduce the amount of memory required to run the build process and avoid running out of memory. ### Conclusion Running out of memory in a build container can be a frustrating issue to encounter, but with a few tweaks to your configuration and build process, you can usually resolve the issue. By following the tips outlined in this article, you should be able to get your build process running smoothly once again. --- Title: Running Amazon Linux container images Url: https://support.deploybot.com/build-tools/running-amazon-linux-container-images --- If for some reason you need to use external docker images such as Amazon Linux (for example: [public.ecr.aws/amazonlinux/amazonlinux:2023](http://public.ecr.aws/amazonlinux/amazonlinux:2023)) You will need to keep the full name in the container definition, as in here: Then, the container will be downloaded from the external source and not from the Docker Registry. --- Title: Common issues with Elastic Beanstalk Url: https://support.deploybot.com/common-questions/troubleshooting/common-issues-with-elastic-beanstalk --- ## What is Elastic Beanstalk? AWS **Elastic Beanstalk** is an orchestration service offered from Amazon Web Services for deploying infrastructure which orchestrates various AWS services, including EC2, S3, Simple Notification Service (SNS), CloudWatch, autoscaling, and Elastic Load Balancers. ## How does DeployBot deploy to Elastic Beanstalk? Deploying to Elastic Beanstalk is a simple process. First, we pack or bundle your source code similar to the “[deploy](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb- cli3-getting-started.html#ebcli3-basics-deploy)” step when using the EB CLI tool. Then a new version is created in Elastic Beanstalk, and we make that version current in your environment. ## How does the lack of persistent storage on Elastic Beanstalk affect deployments? Elastic Beanstalk applications run on Amazon EC2 instances that have no persistent local storage. This means each time you push or deploy the local file system is deleted and new Amazon EC2 instances start with a default file system. You can prevent files from being deleted or removed when deploying by designing your application to store data in a persistent data source. Here are a few persistent storage options: [Amazon S3](https://aws.amazon.com/s3/) [Amazon Elastic Block Store](https://aws.amazon.com/ebs/) For more information on how persistent storage works with Elastic Beanstalk please read [Amazon’s developer guide](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.concepts.design.html#concepts.concepts.design.storage). ## Common deployment incidents with Elastic Beanstalk **Incident Error:** ` / AWS::ElasticBeanstalk::Errors::InvalidParameterValue: Source bundle is empty or exceeds maximum allowed size: (\d+)/` **What does this mean?** ElasticBeanstalk rejected your application because it is empty or exceeds the maximum allowed size (currently 500MB). **What we recommend:** Make sure you exclude all auxiliary files from the bundle. Use S3 to store any large assets used by your app. When files are too big you could try [adding certain files to your .gitignore file](http://stackoverflow.com/questions/22366995/error-pushing-to-aws-source- bundle-exceeds-maximum-allowed-size-524288000) to reduce the size of your bundle. ** _Incident Error:_** `/AWS::ElasticBeanstalk::Errors::Throttling: Rate exceeded/` **What does this mean?** AWS Elastic Beanstalk is temporarily blocking our API requests due to rate limiting. **What we recommend:** In most cases, you can try the deployment again and it will work. --- Title: IPs and ports for firewall setup Url: https://support.deploybot.com/common-questions/ips-and-ports-for-firewall-setup --- For the purpose of whitelisting, all of the DeployBot servers reside within the following IP addresses: * 35.160.197.15 * 35.164.109.1 * 35.164.222.16 * 35.165.208.249 * 52.25.14.156 * 52.32.192.9 * 52.32.251.109 * 52.32.69.162 * 52.34.43.222 * 52.35.111.113 * 52.35.132.215 * 52.37.215.92 * 52.38.202.217 * 54.200.148.82 Note: If you want to automate your firewall setup, you can use our DNS record that lists all the IPs as **A records**. You can fetch it with this command: `dig +short servers.deploybot.com` In order for deployments to work properly with your server, you need to make sure that all relevant ports are open in your firewall: * For passive FTP, open ports 20 and 21, and all ports higher than 1023 (up to 65535). * For active FTP, open port 21. * For SFTP, open port 22. * For shell, open port 22. **Will DeployBot work with my VPN?** For security reasons, many corporate networks are behind a firewall or VPN technology. In this type of scenario, using a service like DeployBot will likely not work by default. You will have to contact your IT department or system admins to request that they allow connections to DeployBot's IP addresses (listed above). **Old Network IPs** **If you're looking to remove DeployBot's old network IPs they were:** * **50.31.156.0/25** **These CIDR ranges include: 50.31.156.0 – 50.31.156.127** --- Title: How do I rollback a deployment? Url: https://support.deploybot.com/common-questions/how-do-i-rollback-a-deployment --- ## Rolling back your deployment There can be situations where you need to revert your remote server to a previous state/commit. If you use DeployBot's deployment tools this is really simple. One way is to use **Rollback to** button near on your successful deployments: If you want to rollback to some other commit, you can use a second option. In the Deployments section, click Deployment button. From there, select a previous commit from the dropdown, and deploy. DeployBot will bring the files on your remote server to the state of that commit. Files will be added, edited and deleted as needed to get everything to this previous revision. We will automatically detect that it was a rollback and display it as such in the app. ## **How will rollback work?** You might be wondering (and you should) about how a rollback will work. For a deployment that uploads the files, rollback will revert the changes literally – if a file was added before, it will be removed, if a change was made, it will be unmade, if a file was deleted it will be added back. Things are trickier for deployments that just execute code on your server. In that case, your script will have to react on the rollback on its own – we will provide updated **%COMMIT%** and **%ROLLBACK?%** variables, but you have to make sure your script takes them into account. If you are not sure how a rollback will work in your case, please don't hesitate to ask questions in support, we will be glad to investigate with you and clarify. ## **Rolling back in version control** It's important to note that rolling back the deployment will not revert the files in your repository. The next time you deploy, all the changes that you rolled back will be again uploaded to your remote server. So it is important that you revert or fix the offending changes in your repository as well. Here's an example: * You commit revision 10 and deploy it to the server. * You commit revision 11, deploy it to the server and it breaks your site. * You rollback the deployment to revision 10. * You commit revision 12 that fixes the bug that broke the site, or you revert to revision 10 in version control. * You deploy the most recent revision 12 to the server. In this example all file changes between the revision 10 and 12 will be updated to revision 12 on the server, overwriting any broken code that revision 11 introduced. This will bring your repository and your server to the same state. --- Title: Connecting self-hosted GitLab and other Git Repositories via SSH Url: https://support.deploybot.com/common-questions/connecting-self-hosted-gitlab-and-other-git-repositories-via-ssh --- To connect to a self-hosted GitLab or any other self-hosted Git repository, choose the tab _Others_. Enter the URL of your repository. In case of a SSH- based authentication it looks like `git@...` or `ssh://....` If you're not sure about the correct URL, contact your Git hosting/service provider or the administrator of the self-hosted repository. Activate the _SSH_ key checkbox (default) and click on _Download_ key. You should have a new public key in your Downloads folder; it is named after your DeployBot account's name, followed by a dash and `DeployBot.pub` (for example `agencyX-DeployBot.pub` if your company is called agencyX). If you look at the SSH public key file in a text editor, you should see the structure `` (RSA), `` (Base64-encoded), and ``, for example: ``` ssh-rsa AAAAB3NzaC1yc2EAA[...]R/SPdvP agencyX-deployments@DeployBot ``` ## Correct Location for the public SSH Key Next, you need to copy the public key to the correct location, which is dependent on your server setup. Normally, the key is added to the file `authorized_keys` in the directory `~/.ssh`, where `~` is an abbreviation for your home directory. Please make sure you choose the correct home, i.e. for `git` or any other account you're using to access the repository. The easiest way to add the public key to the `authorized_keys` file is to concatenate it onto the file manually by using the `cat` command: ``` ~$ cat agencyX-DeployBot.pub >> ~/.ssh/authorized_keys ``` **Note:** Make sure to use the `>>` operator to append the key to the file; a single `>` will overwrite it instead! Check the permissions of the directory `~/.ssh` and of the file `authorized_keys`. The directory should be readable (`r`), writable (`w`) and executable (`x`) for the owner, the file `authorized_keys` should be readable (`r`) and writable (`w`) for the owner. To make sure the permissions are correct, you can run the following commands: ``` ~$ chmod 700 ~/.ssh ~$ chmod 600 ~/.ssh/authorized_keys ~$ ls -ld ~/.ssh drwx------+ 42 huhn staff 1344 19 Jun 10:58 /home/git/.ssh/ ~$ ls -l ~/.ssh/authorized_keys -rw-------+ 1 huhn staff 1946 17 Mär 12:31 /home/git/.ssh/authorized_keys ``` Please note that this command needs to be run under the `git` account or any other account you're using to access the repository. If you're having issues connecting to a repository on your server, please don't hesitate to [contact our support team](mailto:support@deploybot.com); we are always glad to help! --- Title: How do SFTP deployments work? Url: https://support.deploybot.com/common-questions/how-do-sftp-deployments-work --- Firstly, DeployBot offers two kinds of SFTP deployments: file deployments and atomic deployments. File deployments upload files directly to the directory that you specify. They iterate over changes since the last deployed Git commit in lexicographical order removing or uploading files one-by-one as an FTP/SFTP client would. Atomic deployments work differently. They maintain a special directory structure on your server that allows DeployBot to store last N releases and switch between them using symlinks. This is why atomic deployments are often referred to as zero-downtime deployments. ## What gets changed? We only update changed files in your Git repo since the last deployment. But, if you’re using build tools, all build artifacts such as minimized assets, etc. (and only build artifacts) are deployed from scratch _every time_. ## What is the order of events? File SFTP deployments have pre- and post-deployment commands. Those run on the server against the live version, before or after the file transfer. Atomic SFTP deployments have post-upload commands, but they don’t have pre- deployment commands since atomic uploads are non-intrusive. These run on the server against the newly uploaded version. Additionally, atomic deployments allow you to specify commands to run when a newly uploaded version becomes active. ## How exactly do atomic deployments work? To provide seamless version rollouts, atomic deployments have to maintain a special directory structure on your server: * releases — contains cached copies of your releases including the currently active release. * deploy-cache — contains the last uploaded state. **Manually modifying this directory will break your deployments.** * shared — contains your [shared resources](//support.deploybot.com/article/87-managing-shared-files-and-directories-with-atomic-deployments): user-uploaded content, file caches, etc. * current — a symbolic link to the currently active release from the releases directory. These directories will be created in the destination path specified in atomic server settings. When you trigger a deployment, the following actions take place: 1. DeployBot makes sure all the directories mentioned above exist and creates the missing ones. 2. DeployBot updates the copy of your code in a cache directory on your server. 3. When the code is updated, DeployBot copies that code to a separate release directory. 4. In the release directory, DeployBot executes user-specified post-upload commands to get code into shape — like installing application dependencies or [linking shared resources](//support.deploybot.com/article/87-managing-shared-files-and-directories-with-atomic-deployments). 5. Once the release is ready, the _current_ [symlink](https://en.wikipedia.org/wiki/Symbolic_link) is updated to point to a new release directory. 6. User-defined commands are then executed to restart your application server, prune caches, or notify external services. 7. DeployBot removes previous versions of your apps from the releases directory, keeping only a fixed number of newest ones. This number is configurable via advanced server settings. **Please note:** We don’t support SFTP deployments to Windows hosts. --- Title: How do I trigger pre- and post-deployment web hooks? Url: https://support.deploybot.com/common-questions/how-do-i-trigger-pre-and-post-deployment-web-hooks --- When it comes to deployments, some environments require extra tasks to be executed before or after files are uploaded. DeployBot supports two types of deployment hooks: pre- and post-deploy web hooks and a post-deploy shell command hook. ## Pre- and Post-deploy web hooks Deployment web hooks are supported for all deployment server types. They require that you have a web server running on your remote machine that can be accessed by DeployBot whenever a web hook is triggered. When the hook is triggered, DeployBot will connect to your web server at the URL you specify and submit information about the triggered deployment in JSON format. You can set up the URL that your web hook is listening to on the server setup page. Make sure your web server is always returning a 2XX HTTP response to DeployBot in order for it to be considered a success. If a pre-deployment hook returns anything other than a 2XX response, the deployment will not proceed and no files will be uploaded. If the post-deployment hook failed, DeployBot will mark the entire deployment as failed to alert you of the issue. If you would like to protect your web hook with a password, you can use basic HTTP authentification by providing the username and password in the web hook URL, like this: ``` https://myuser:mylogin@www.mydomain.com/myhook ``` _Please note, if you have a firewall on your server you’ll need to whitelist_[ _DeployBot’s IPs_](//support.deploybot.com/article/96-ips-and-ports-for- firewall-setup) _in order to receive the hook._ ## Pre-launch shell commands Pre-launch shell commands are available only for SFTP servers. DeployBot will execute these shell commands on your remote server after your updates are uploaded, but before new code becomes the current running code. _This is ideal for compilation or building assets_. Make sure that all of the specified shell commands return an exit status of 0 in order for them to be considered a success, otherwise the deployment will be marked as failed so you can see that there was a problem. ## Post-launch shell commands Post-launch shell commands are available only for SFTP servers. DeployBot will execute these shell commands on your remote server after the deployment is finished. _This is the best place to restart your web server_. Make sure that all of the specified shell commands return an exit status of 0 in order for them to be considered a success, otherwise the deployment will be marked as failed so you can see that there was a problem. #### A sample of JSON data posted by DeployBot ``` ;{ "author":"author username", // username of the author "repository":"deploybot", // repository from which data was or will be deployed depending on whether its a pre or post hook "author_name":"John Smith", // full name of the author "comment":"example", // commit message "author_email":"johnsmith@example.com", // email of the author "server":"server example", // server to which data was deployed or will be deployed depending on whether its a pre or post hook "environment":"development", //environment from which data was or will be deployed depending on whether its a pre or post hook "revision":"5", // revision to which the deployment will be updated "deployed_at":"deployed at date", // time when deployment happened - timezone is included, will be null for pre hook "repository_url":"git@example.beanstalkapp.com:/example.git", // source control url of the repository "source":"beanstalkapp.com" // identifier of the payload, in case you consume JSON from many vendors } ``` **PHP users please note** that in order to get contents of a POST request in PHP you need to use the following code snippet: ``` @file_get_contents(php://input); ``` --- Title: How to deploy to WP Engine Url: https://support.deploybot.com/common-questions/how-to-deploy-to-wp-engine --- [WP Engine](https://wpengine.com) is a popular WordPress host. DeployBot supports deploying your WordPress site that is in a Git repository to WP Engine through SFTP deployments. Below are the steps to connect WP Engine with DeployBot. ## **Creating an SFTP login in WP Engine** First, you’ll need to create an SFTP login in WP Engine. To create your login navigate to the install page in the WP Engine user portal (https://my.wpengine.com/installs). From the install page, choose the WordPress install that you’d like to create your SFTP login. After selecting the install scroll to the bottom of the page and click “Add Login”. You’ll then be able to create your SFTP login. For the user, you’ll be prompted to create the following details: **Username** \- This is the SFTP username. The username will follow the convention of _wp_engine_account_name-username._ **Password** \- The password for your SFTP user. **Path** \- This is the directory in WordPress where your SFTP user will deploy to. By default, you’ll want to keep this blank, when left blank the path will be the root directory in your WordPress install. The path is if you are using DeployBot to deploy a particular directory on your WordPress site (i.e., wp-content/plugins/plugin-name). **Environment** \- With each WP Engine WordPress install you are given a Production (install-name.wpengine.com) and staging (install- name.staging.wpengine.com) site. Choosing the environment allows you to pick what site your SFTP user has access to. After filling in the above information, click on “Add SFTP login”. This login is now ready to be connected in DeployBot. ## **Connecting your SFTP login to DeployBot** After creating your SFTP login, you’ll need to add WP Engine as a server to deploy to in DeployBot. To do so, go to the Server & Settings section in DeployBot for the environment that you’ll be connecting and click on “Add Server”. On the “Add new server” page click on SFTP. On the “Add a new SFTP server” page you’ll be able to enter your WP Engine Server details. **Name** \- Choose a title for the SFTP connection, pick something that will be memorable for you **Host** \- The address of your WP Engine site. It can be either the Server IP address for your install or you can use DNS where it’ll look like _install- name.wpengine.com_. **Port** \- WP Engine SFTP uses port 2222. **Destination path** \- This is similar to the path option in WP Engine. DeployBot will deploy to the root directory the user has access to in WP Engine. If you’d like to, DeployBot can handle deploying to a specific directory on your site that can be set here. Otherwise, it’s best to leave this blank. **Username** \- The SFTP login username created in WP Engine. **Password** \- The SFTP login password created in WP Engine. After entering the SFTP login information, you can make any DeployBot setting changes that are necessary like excluding file paths from your repository for deployment or choosing the current commit in the repository to deploy from. Save the changes at the bottom of the page and DeployBot will add your WP Engine SFTP connection. After DeployBot connects to WP Engine, the Servers & Settings page for your environment will list your SFTP connection with a “Connection Established” message. ## **Deploy** After setting up your SFTP login information in DeployBot, you’re ready to deploy your WordPress site to WP Engine! Do you have questions on deploying to WP Engine? Don't hesitate to contact our support. We are always glad to help. --- Title: Connecting your GitHub repository to DeployBot Url: https://support.deploybot.com/common-questions/connecting-your-github-repository-to-deploybot --- Click the **“Repositories”** tab and select the **“Connect a repository”** button in the top left. Next, you’ll need to select the “**GitHub** ” box displayed at the top of the screen. Then select the “**Connect a new account** ” button which will redirect you to the GitHub authentication page. After authenticating your GitHub account, you can select your repository from the dropdown. After connecting to your repository, you’ll need to add DeployBot’s webhook to your GitHub account. This allows DeployBot to refresh the list of commits automatically, and to make automatic deployments possible. Go to your **repository > Settings >** **webhooks** and badges to locate your webhook. ### **Adding the webhook to Github** To add the webhook to GitHub, go to your repository settings in GitHub. Then select **webhooks and services** from the side menu list, and click “**Add webhook** ”. **Please note:** By default, DeployBot will connect to your GitHub repository using an SSH URL. You can change that on your repository settings page. **Also note:** [DeployBot now provides an assistant](https://deploybot.com/blog/say-hello-to-your-new-deploybot- assistant) which describes in detail each element which takes part in connecting your repository. --- Title: How do I avoid deploying from scratch on my first deployment? Url: https://support.deploybot.com/common-questions/how-do-i-avoid-deploying-from-scratch-on-my-first-deployment --- #### Selecting a specific commit for your server in your environment When you set up a new server in DeployBot, the first deployment will always be deployed from scratch. This means DeployBot will take all the files in the repository and upload them to your remote server. This is done to ensure that your repository and files on your remote server are in sync. DeployBot will memorize the commit that was deployed and all future deployments will be done incrementally from that commit. While this works great when the remote server’s directory is empty, for those customers who already have existing files on the server, it can cause issues. For this reason, our deployment tools allow you to choose the most recent revision that exists on your remote server from which DeployBot will start deploying. For example, say your repository is currently at commit 659f9aa2. All the files up to that commit are already on your remote server. You want to set up a new deployment server in DeployBot, but you don’t want it to re-deploy all those files that already exist on your remote server. To do that you would need to set commit 659f9aa2 as the starting commit on the setup page. After that is done, DeployBot will assume that your remote server is up to date to commit 659f9aa2, and will only deploy incremental changes starting from that commit. _Please note, leaving DeployBot to deploy from scratch will not break anything. If you have all the files on your server, it will just take longer for us to deploy. It may, however, bring something on your site offline depending on the way your web server is configured._ To select a commit to deploy from, click the 'Advanced options' section in the server setup page and use the 'Current commit' dropdown menu to select the commit. --- Title: Restricting access by IP Url: https://support.deploybot.com/common-questions/restricting-access-by-ip --- In some cases, you might want to only allow certain IP addresses to access your DeployBot account. By reviewing the [IP access log](//support.deploybot.com/article/120-ip-access-log), you can easily see who is accessing your DeployBot account, including their IP address. You can then enable IP restrictions and add these safe IPs to a whitelist in DeployBot. IP address restrictions are disabled by default. To restrict access from certain IP addresses, log in to your DeployBot account, go to the Accounts page, then go to the Security section. Then click the "Enable restricted access" button. After enabling the restriction, no users will be able to access your account (except you, the account owner), until you add their IP addresses to the whitelist or disable IP restrictions. When adding IP addresses, you can add one IP address or an IP address range, which allows access to multiple IP addresses in the same range. **Please note that you have to be the account owner to be able to restrict access by IP address.** --- Title: How do I handle authenticating to private submodules Url: https://support.deploybot.com/common-questions/how-do-i-handle-authenticating-to-private-submodules --- If you’re deploying to private submodules, you’ll want to keep a few things in mind. ## Step 1: Authenticate to your private submodule using SSH URLs You **must** use an SSH URL to authenticate. You cannot use an HTTPS URL to authenticate to your private submodule. The SSH URLs should be included in your _.gitmodules_ file. Otherwise, DeployBot will not be able to connect. **Note:** If you receive an error message that says, “no credentials provided” that means it’s likely you’re using an HTTPS URL and not SSH. ## Step 2: Add the public submodule key to your repository If your submodules are protected repositories, use the “public key for submodules” to authenticate to these repositories. You can find this key by going to **Repository > Settings** and scroll to the bottom of the page. You can configure deployment key or just a regular key with read-only permissions in your repository hosting service. ## Step 3: Create a dedicated user for deployments This is an important step. Add the DeployBot public SSH key for submodules to your user and allow them access to the necessary repositories. A dedicated user will resolve many common permission issues with submodules. If you’re a GitHub user, visit GitHub to learn more about their [recommendations for dedicated users.](https://developer.github.com/guides/managing-deploy-keys/#machine- users) # Common issues with Submodules ## I changed the repository URL from HTTPS to SSH. But my deployment still fails. What’s going on? If you’re still receiving an error after changing your submodule URLs to SSH try deploying again using the “redeploy from scratch” option. DeployBot will then take everything in the repo and deploys it to the end destination. You can enable this option on the deployment screen. ## DeployBot couldn’t update the submodules for my repository. How do I fix this? **What we recommend:** * Please check if all the repositories used as submodules allow DeployBot to access them. Please see **step 2** in the section above. * Make sure that your main repository links to commits in submodules that are currently present. * If submodule repository was rebased or commits were deleted from it, you may need to update your main repository with a link to a new commit. ## While trying to checkout my repository for a deployment a submodule failed to update. **What we recommend:** * Check to see if your submodules are requiring authentication to access. * Make sure that you can make a clone of the repository and initialize all the submodules. Very often this problem is caused by submodules which were not deleted correctly from the repository. ## I added the DeployBot key to my Github repository but it says the key is already in use. How do I fix this? In this scenario, it’s likely that you’re trying to authenticate to two or more repositories with the same key. GitHub recommends creating a specific user for this type of setup. This “machine” account can have its own set of keys. Usually, there's a main repository and secondary repositories. **What we recommend:** 1. Create a separate GitHub user, just for deployments. See **step 3** in the section above. 2. Move your key from the main repository to that user. 3. Give that user access to all the repositories you need to deploy. This process is a bit involved, but this is how [GitHub recommends](https://developer.github.com/guides/managing-deploy-keys/#machine- users) handling these situations. **Note:** This is not to be confused with a deployment key. This is for _authenticating to the repo_ itself, not necessarily what we call a “deployment key". --- Title: How Do I Trigger My Deployments? Url: https://support.deploybot.com/common-questions/how-do-i-trigger-my-deployments --- DeployBot has two primary modes of deployment: Automatic and Manual. Automatic deployments will happen with each push made to your remote repository. Manual deployments can be initiated from the Deploy button in the DeployBot web-app. To set your deployment mode, navigate to your environments **Servers & Settings**. The deployment mode is found in the General Settings section. ## Can I schedule deployments with DeployBot? Currently, DeployBot does not have scheduled deployments as we believe that humans should be involved in the deployment process. This especially applies to Production environment deployments where we think they shouldn’t be accidentally scheduled while the team is sleeping. ## Other Deployment Methods Through a [Webhook call](https://deploybot.com/blog/trigger-deployments-with- a-webhook-call) and the [API](https://deploybot.com/api/deployments#trigger- deployment) DeployBot extends the ability to deploy. And trigger deployments in Slack by [creating a slash command](https://deploybot.com/guides/chatops- deploybot-slack). For Manual deployments, a commit message that contains `[deploy: environment- name]` will trigger a deployment to the specified environment. If the environment name has a space, wrap the name in quotes (i.e., `[deploy: "environment name"]`). --- Title: How do I set up public key authentication for SFTP/Shell deployments? Url: https://support.deploybot.com/common-questions/how-do-i-set-up-public-key-authentication-for-sftp-shell-deployments --- If you are setting up SFTP or shell deployments, we offer the option to add extra security by using public key authentication. In order to use key authentication, you’ll need to add a key to your server that we will check each time a deployment is triggered. From the server settings screen, you’ll have the option to download a public key. You’ll need to add this to the authorized_keys file for the user you are deploying with (usually located under your user directory at **~/.ssh/authorized_keys**) on your server. **All servers added to the same repository are authenticated with the same key** , so you don't need to download the key every time. If you are having authentication issues, please follow the tips in our [help article](//support.deploybot.com/article/66-i-cant-deploy-to-a-ssh-or-sftp- server). --- Title: How do I cancel or retry a deployment? Url: https://support.deploybot.com/common-questions/how-do-i-cancel-or-retry-a-deployment --- #### Canceling a deployment If you’ve decided that you don’t want to complete a deployment you’ve triggered you can cancel it easily. Any deployment that’s In Queue or Deploying can be canceled. Please note that if deployment has the **Deploying** label, we have started the transfer. Some files might have already been synced with your server. While the deployment is still in queue, the deployment did not start yet, so it's safer to cancel. #### Retrying deployment If a deployment failed or if you canceled it, there will be a **Retry** button next to it in the Activity. Clicking Retry will have DeployBot deploy it again. --- Title: Responsible Disclosure Policy Url: https://support.deploybot.com/common-questions/responsible-disclosure-policy --- Keeping customer data safe and secure is our top priority. If you've discovered a security vulnerability, **please do not share it publicly**. Instead, report it to us using our [security response form](https://docs.google.com/forms/d/e/1FAIpQLSfuMgTNfc8JA8xPfByIxGfvWlUQM3CQEANO6CY7Io9VTfDwbQ/viewform). ## Rules for you * Avoid data deletion, unauthorized data access, and service disruption while testing the vulnerability you found. * Do not access or modify, or attempt to access or modify, data that does not belong to you. * Do not execute, or attempt to execute, a Denial of Service (DoS) attack. * Do not run any automated tools against our servers without prior coordination. * Do not try to abuse our servers’ resources, including but not limited to sending unsolicited or unauthorized emails. * Do not publicly share the issue details until we confirm that it’s fixed. * Do not attempt to blackmail us, or try to sell us your security report. * When in doubt, contact us at support@deploybot.com. ## Rules for us * We will not pursue any legal action against you if you obey the rules above. * We will reply to all correctly submitted reports, and we will work with you on fixing the issue. * We will perform our own risk assessment for every reported vulnerability. * If your report is not eligible, we will let you know the reason why. * We will let you decide whether you want to be publicly acknowledged for your report. ## Hall of Fame For eligible reports, we can acknowledge your work by putting your name and (optionally) a link to your personal page on the list of security contributors below. ## Bounty * We do not offer cash compensation for security reports. * For some eligible reports that we identify as particularly important, we may reward you with our branded stickers or a t-shirt. If you’d like to receive something from us, please put your mailing address in the security response form, or share it later when we confirm the eligibility of your report. ## What does not qualify? * Vulnerabilities to timing and DoS attacks (remember, you’re not allowed to test these). * Vulnerabilities that have been previously reported by another user. * Known vulnerabilities in the components of our technological stack reported within 48 hours since their public reveal. * Security issues, only reproducible under highly unlikely conditions (using outdated or exotic web browsers or operating systems). * Bugs or functionality that proves that a tested email address exists in our database as well as the theoretical ability to brute-force such functionality. * Vulnerabilities that we determine to be an accepted risk, including but not limited to: * Ability to sign up and use our services without confirming an email address. * Lack of CAPTCHAs on the forms. * Lack of use of hardfail (-all) on SPF records. * Lack of a "reject" record in DMARC. ## Thanks for your support! We're grateful to the following people who have helped us improve the security of DeployBot: **Indrajith.AN** [indrajith.cyberXdestroyer](https://www.facebook.com/Intruderhex) **Shivam Kumar Agarwal** **Mandeep Jadon** [1337tr0lls](https://twitter.com/1337tr0lls) **Anil R. Vaghasiya** [Facebook](https://www.facebook.com/anil.vaghasiya.9), [Twitter](https://twitter.com/anil_vaghasiya) **Muhammad Awais Noshahi** **Nithish M. Varghese**[Facebook](https://www.facebook.com/nithish.varghese) **Kalpesh Makwana** [Twitter](https://twitter.com/makwanakalpesh2) **Mansoor Gilal** [Facebook](https://www.facebook.com/mansoor.gilal1) **Jay Patel** [Facebook](https://www.facebook.com/jaypatel9717) **Balvinder Singh** **Arbin Godar** [Twitter](https://twitter.com/arbingodar) **Daniyal Nasir** **Sajibe Kanti** [Facebook](https://www.facebook.com/sajibe.kanti), [Twitter](https://twitter.com/Sajibekantibd) **Md. Nur A Alam Dipu** [Twitter](https://twitter.com/Dipu1A) --- Title: What are the different states of a deployment? Url: https://support.deploybot.com/common-questions/what-are-the-different-states-of-a-deployment --- DeployBot deployments can have the following statuses: * In Queue * Deploying * Successful * Failed * Bypassed #### Deployment in queue When you initiate a deployment in your DeployBot account, it will pick it up, and put it in queue. Most of the time this is hardly noticed since deployments process quickly. If you see a deployment in queue for a bit, it may be because we’re handling a huge volume of deployments at the moment. #### Deployment in progress When files are being deployed to your server, it will be labeled as **Deploying**. As long as you see this state, files are being synchronized with your server. When the deployment is finished, the label will disappear. #### Deployment was successful Once a deployment finished successfully, we’ll remove the **Deploying** label. By clicking on the deployment, you will be able to see the release notes and details about the deployment. #### Deployment failed If we were unable to complete the entire deployment, you will see a **Failed** status. There could be many reasons why deployment would fail so we will link to the specific incident where you can find out more details on what happened. If you hover over the **Failed** label you can see short description on why the deployment could have failed. #### Deployment bypassed If we didn’t deploy a specific revision for some reason, you’ll see a **Bypassed** label. There are a few reasons why this can happen. A deployment will be bypassed if a new deployment was created before it started deploying. It can also be bypassed if DeployBot couldn’t find changes in the repository path you specified. [Learn more](//support.deploybot.com/article/110-why-was- my-deployment-bypassed) about why deployments are bypassed. --- Title: Connecting your Bitbucket repository to DeployBot Url: https://support.deploybot.com/common-questions/connecting-your-bitbucket-repository-to-deploybot --- To connect your Bitbucket repository to DeployBot click the **“Repositories”** tab, then select the **“Connect a repository”** button in the top left. Next, you’ll need to select the “ **Bitbucket** ” box displayed at the top of the screen. Then select the “**Connect a new account** ” button. After authenticating your Bitbucket account, you can select your repository from the dropdown. After connecting to your repository, you’ll need to add DeployBot’s webhook to your Bitbucket account. This allows DeployBot to refresh the list of commits automatically, and to make automatic deployments possible. Go to your **repository > Settings > ****Webhooks & Badges** to locate your webhook. ### Adding the webhook to Bitbucket To add the webhook to Bitbucket, go to your repository settings in Bitbucket. Then select “ **Webhook** ” from the side menu list, and click “**Add webhook** ”. **Please note:** By default, DeployBot will connect to your Bitbucket repository using an SSH URL. You can change that on your repository settings page. --- Title: Can I password protect my Atom feeds? Url: https://support.deploybot.com/common-questions/can-i-password-protect-my-atom-feeds --- By default DeployBot uses token authentication for all Atom feeds. Every user has his own unique secure token that is built into every RSS feed that a user has access to. Token authentication is very convenient as it doesn't require a user to enter their username and password each time they access a feed. It is also supported by the vast majority of feed readers. However, token authentication can be potentially dangerous if users choose to share their feed URLs, which we strongly recommend not to do. Account owners can switch their accounts to use regular and more secure password authentication for all RSS feeds. This kind of authentication will require a username and password every time the feed is accessed. While password authentication provides more security, it isn't supported by many popular feed readers, so we made it optional. You can turn on password authentication for atom feeds in **Account** → **Security** : --- Title: Why was my deployment bypassed? Url: https://support.deploybot.com/common-questions/why-was-my-deployment-bypassed --- There are two major reasons a deployment can get bypassed: no changes were found or there was a newer deployment triggered before this one was started. ## No changes found in the repository path When you trigger a deployment, DeployBot will check that you've made changes in the specific repository path you've set up. If we don't find changes, we'll skip the deployment. You want to make sure to check the repo path you've specified and make sure that you made a change in that directory/branch. ## A newer deployment was triggered When a deployment is triggered, it gets queued up to go out. It usually takes only a few seconds, but there can be a chance that someone triggers a newer deployment in that time. In this case, we'll skip the first one and deploy the newer one since you always want newer changes on your server. --- Title: Connecting a Beanstalk Repository to DeployBot Url: https://support.deploybot.com/common-questions/connecting-a-beanstalk-repository-to-deploybot --- DeployBot allows you to connect to the [Beanstalk](https://beanstalkapp.com/) version control system to deploy code from Git repositories. To connect a Beanstalk repository, go to your DeployBot repositories page. Click on **Connect a repository** in the top left. On the connect to a repository page click on the third option, self-hosted. Next, you'll need to know your repository URL; this can be found in Beanstalk by going to the activity page of your Beanstalk repository. You'll have the option to choose your authentication method; you can use your Beanstalk username/password. Next, you can choose a name and color labels you'd like to add to the repository. Click on the **Connect** button and DeployBot will connect to your Beanstalk account. The page will reload and show the connected repository. #### **Setting up automatic deployments** After setting up your repository in DeployBot, we suggest adding a Webhook to Beanstalk enabling automatic deployments by pushing commits to DeployBot. Without this setting, deployments will need to be manually refreshed in DeployBot. To do so, go to to the **Settings** page for your repository in DeployBot, then click on **Webhook & Badges**. In the top section, copy the URL under Refresh repository. In Beanstalk, browse to the Integration page for the desired repository (under **Settings**) and follow these steps: * At the bottom of the page, click the Modular Webhooks integration * On the following page, click **Add a webhook** * From there, paste in the URL you copied from your DeployBot account, check the box beside push and then click **Save** Now each push to your repository will automatically trigger a deployment in your desired DeployBot environment. At the bottom of the page click on the Activate button and your Webhook will be enabled. Beanstalk will now send changes to your DeployBot whenever there is a push to the repository. --- Title: Deploying to a DigitalOcean droplet Url: https://support.deploybot.com/deployment-integrations/deploying-to-a-digitalocean-droplet --- [DigitalOcean](http://digitalocean.com) is an amazing cloud hosting provider. They provide SSD-based cloud servers for as little as $5 in different data centers, and you can get your server up and running in a matter of minutes. Naturally, we think this is a great target for DeployBot deployments — we want deployments to be as easy to get running as possible. **Add your DigitalOcean Personal Access Token to DeployBot** First of all, you need to generate a Personal Access Token on DigitalOcean so you can add this to your DeployBot account. The token can be generated under the API section on your DigitalOcean account. When you generate the token, be sure to select the 'Write' option. For security purposes, the token will be shown one time only, so please copy it. If you forget it or don't copy it down, you can always regenerate the token at a later time. Once you have copied the token, you can add it to DeployBot under the Settings > Integrations page. Click the 'Connect' button, enter a name for your connection in the Label field, and paste the token into the Personal Access Token field. After connecting your account, DeployBot will be able to add unique SSH keys to DigitalOcean, and when you create new droplets you’ll be able to add that key right away, giving DeployBot access to deploy to those servers. Unfortunately DigitalOcean doesn’t allow adding keys to existing servers, so this needs to be done manually. (We provide the commands to do this on the server settings page.) **Create a server and connect it to your DigitalOcean droplet** Go to your environment settings page and click the 'Add a server' button. You’ll notice there are two DigitalOcean choices. The web applications choice will set up an [atomic deployment](http://deploybot.com/blog/deploy-complex- apps-with-atomic-sftp-deployments), and allows you to deploy complex web apps with zero downtime to your droplet. The files (non-atomic) choice is a reliable and secure way to upload files to your droplet using an encrypted connection. It can also be used to deploy web applications that are insensitive to runtime filesystem changes or have relaxed uptime requirements. **Atomic deployment set up** If you chose the atomic deployment, you'll see a screen similar to the one below: Pick a name for your new server, then select a droplet you want DeployBot to deploy to. The commands to add the DeployBot SSH key to your DigitalOcean droplet are available if you click the “Show the commands to add our public key to your server.” link. If you are using a different deployment user or a non-standard SSH port, you can change these under the Advanced options block at the bottom of the page. _Please note that by default all DigitalOcean droplets are created using only the root user, so DeployBot uses the root user as the default user for the deployment._ In the 'Application path' field, enter the path that DeployBot should deploy your web application to. If you click on the 'Show paths that will be created on your server' link, you will see the various paths that will be created by DeployBot for the atomic deployment: You will need to adjust the target path of your current web application to include the new 'current' directory that DeployBot uses for the deployment. **What happens during an atomic deployment?** * When you deploy we update the copy of your code in a cache directory on your server. * When the code is updated, we hardlink that code to a separate release directory. * In the release directory we execute all of the user-defined commands required to get code into shape — like compiling assets or fetching dependencies through bundler or composer. * Once the release is ready, the current symlink is updated to point to a new release directory. * User-defined commands are then executed to restart your application server or related services. If even one of those steps fail, your current running code is unaffected, as we delay updating the current symlink until the very end of the deployment. Old releases are preserved in case you need to roll back for an emergency, but are cleaned up for you when there are too many of them (this value is configurable in the 'Advanced options' block). The very last step is to click the 'Save' button at the bottom of the page. You are now ready to deploy to your DigitalOcean droplet! **Non-atomic deployment set up** If you chose the non-atomic deployment, you'll see a screen similar to the one below: Pick a name for your new server, then select a droplet you want DeployBot to deploy to. The commands to add the DeployBot SSH key to your DigitalOcean droplet are available if you click the “Show the commands to add our public key to your server.” link. You can also specify the remote path for DeployBot to deploy your files. Enter the path you want DeployBot to deploy your files to in the 'Remote path' section. It is best to use the full path name here, for example: /var/www/html If you are using a different deployment user or a non-standard SSH port, you can change these under the Advanced options block at the bottom of the page: _Please note that by default all DigitalOcean droplets are created using only the root user, so DeployBot chooses the root user as the default user for the deployment._ The very last step is to click the 'Save' button at the bottom of the page. You are now ready to deploy to your DigitalOcean droplet! **Troubleshooting SSH connections** The most common connection issues we see come from SSH authentication problems. You can check the following things to resolve the problem: Make sure that the authorized_keys file is located in home directory of the droplet user you're using for the deployments. Remember that by default the root user is used, so the file should be added to the /home/root/.ssh/ directory. Also check that the permissions on it are set to 0600. You can set the correct permissions for the file with this command: ``` chmod 0600 /home/root/.ssh/authorized_keys ``` Check that the key you downloaded from DeployBot is properly inserted in the authorized_keys file. Each key in the authorized_keys file should be on a separate line, in this format: ``` ssh-rsa AAAAB3...long-key-here...hUIo6uTLn staging-deployments@deploybot.com ssh-rsa AAAAB3...long-key-here...7bSkeiFdQ production-deployments@deploybot.co ``` If you are using the root user to deploy, confirm that the user is allowed to use SSH to log in. On Linux, check the 'PermitRootLogin' setting in the /etc/ssh/sshd_config file. If you have a firewall set up, be sure to add the IP addresses from DeployBot. You can find these in our [help document](//support.deploybot.com/article/854-ips-and-ports-for-firewall- setup). --- Title: Shell (SSH) deployments Url: https://support.deploybot.com/deployment-integrations/shell-ssh-deployments --- #### Setting up the Server Shell deployments allow you to trigger shell commands on your remote server when you commit or push to DeployBot, or directly from your DeployBot account manually. To use shell deployments you’ll need to specify a server name, server address (URL or IP), port, credentials and the shell commands you want DeployBot to execute during deploy. In the commands section, you’ll specify all of the shell commands that you would like to run on your remote server, each command on a separate line. There are some variables that you can use in your commands: * `%AUTO?%` returns 1 or 0 to indicate if the deployment was triggered automatically * `%BRANCH%` branch that is being deployed * `%COMMENT%` deployment comment (or last commit message for automatic deployments) * `%COMMIT% or %REVISION%` commit that is being deployed * `%ENV_NAME%` name of the current environment * `%FROM_SCRATCH?%` returns 1 or 0 to indicate if the deployment is from scratch * `%RELEASE_ID%` unique ID for the deployment (this stays the same during retries) * `%REMOTE_PATH%` remote path from the settings of the deployment server * `%REPO_NAME%` name of the repository being deployed * `%REPO_URL%` URL of the repository being deployed * `%ROLLBACK?%` returns 1 or 0 to indicate if the deployment is a rollback * `%TIMESTAMP_UTC%` time when the deployment was triggered (formatted in UNIX time) * `%USER_NAME%` name of the user who triggered the deployment * `%WORKING_DIR%` working directory from the settings of the deployment server **Please be careful when using shell commands, shell deployments are powerful but also dangerous. Please double check the commands before finishing setup.** If you need more variables to be setup in your deployments, just let us know. --- Title: How do DeployBot and Slack work together? Url: https://support.deploybot.com/deployment-integrations/how-do-deploybot-and-slack-work-together --- It is possible to use Slack in tandem with your DeployBot account. If you would like to have DeployBot deployment notifications in Slack, or to trigger a deployment from Slack itself, read on. ## Deployment notifications For any repository in your DeployBot account, navigate to the Settings > Integrations page from the menu at the top of the page. Click Connect next to the Slack icon. You will then need to grant DeployBot limited access to your Slack account. Click the Authorize button to grant this access. For each environment that you want to be notified of in Slack, go to Environment Settings, and under the Triggers section, check the “Notify Slack” box. Then choose the channel name where the notifications should be directed. That’s it, now you’ll never miss a deployment again! ## Triggering deployments from Slack It is possible to use Slack’s slash commands for various functions and integrations. DeployBot is no different. You can think of slash commands as regular messages that start with a slash (/) character. When sent, if the Slack server recognizes the command, it executes it according to default rules. Some connected 3rd party apps may add new slash commands to your Slack, and your own team can define custom slash commands too. And now, a little known fact: DeployBot’s deploy webhooks support Slack’s formatting and can be used as target URLs for slash commands. Start with picking a name for your future slash command. You can use a descriptive token like /deploybot-production, or go wild with /letsroll, /dragonsahead, or whatever you like. Just remember to let your teammates know what this is about. Once you’re satisfied with the command name, browse to your Apps & Integrations page in Slack and click “Add Slash Command Integration”. This can be a little hard to find, so here is the full path: * Start here: https://_youraccountname_**.slack.com/home** * Click Configure Apps in the sidebar * Click Build in the menu at the top right of the page * Click on the Make a Custom Integration box * Choose Slash commands from the list * Use the name you’ve chosen To configure the command you’ll need a webhook URL for triggering deployments. In DeployBot, go to “Webhooks & Badges” section of your repository settings, and copy the one associated with your environment of choice. Now let’s go over the configuration fields of a slash command integration in Slack: 1. Command: The name you picked when you created the integration. Feel free to modify it if you changed your mind. 2. Request URL: The deploy webhook URL you copied from DeployBot, paste it here. 3. Short Description: Explain what this command will do. 4. Escape channels, users, and links sent to your app 5. Preview of Autocomplete Entry That’s it. Happy deploying! ## Common Issues **If a deployment is triggered from Slack, who shows as the deploying user?** The committing user is shown as the one deploying in your DeployBot account. Because a deployment can be triggered by anyone who has access to Slack, even if they do not exist in your DeployBot account, we use the commit information to show the deploying user. **Why do I not see my channel in DeployBot?** There are some scenarios where DeployBot will not see a new channel in your Slack account. 1. If your account was renamed, simply click the Connect button once again from the Settings > Integrations page in your DeployBot account. 2. If the connection from Slack has been interrupted and new channels are not showing, you can rename your Slack channel, then change it back to the original name. This will force a re-sync. **We’re missing notifications in Slack. What do I do?** In some situations with multi-server environments, a deployment may fail or be skipped. There are times when this results in no notification being sent to Slack. You can add the following command in DeployBot to put a delay on one server in an multi-server environment: `sleep 5` This will increase the chances that the delayed server will complete successfully, even others do not. --- Title: Deploying static sites to Amazon S3 Url: https://support.deploybot.com/deployment-integrations/deploying-static-sites-to-amazon-s3 --- DeployBot supports deployments to Amazon Simple Storage Service (S3). DeployBot can upload files from your Git repository to your S3 bucket either automatically on every commit or push, or manually. Deploying to Amazon S3 has some unique uses and advantages. Here are some ways that you can use S3 in your deployment process. Please note that in order to use S3 deployments you need to have a working [Amazon Web Services](http://aws.amazon.com/) account. #### Deploy website assets to S3 Amazon S3 is a great place to deploy assets, such as images, media, CSS or JavaScript files. Instead of deploying your assets to your web servers directly, you can deploy them to S3 and link to the assets in your site or application. You can also simultaneously deploy your code to your servers and your assets to S3 in one click or action. #### Globally distribute files on Amazon CloudFront CDN If you host your assets or other files on Amazon S3, you also have the option to include this bucket in Amazon's CloudFront service, a globally distributed Content Delivery Network. CloudFront allows you to serve your files across many servers around the world, allowing customers to obtain low latency and high transfer speeds from any location. For instance, if you deploy your site assets on CloudFront, every user accessing your site will be served assets from the closest location, drastically improving response time on your site. To learn how to setup CloudFront invalidation in DeployBot check our [help article](//support.deploybot.com/article/54-invalidate-cloudfront- distribution). #### Host and deploy static HTML Amazon S3 allows you to easily host static HTML sites, including error pages. If you have simple web sites with HTML, images, and CSS you can deploy your files from DeployBot to an S3 bucket and instantly have a usable site. You can even point your own domain name to the bucket. For complete instructions on setting up static sites with S3, please [read their documentation](http://docs.amazonwebservices.com/AmazonS3/latest/dev/WebsiteHosting.html). **Note: We require the following permissions for S3:** * s3:ListAllMyBuckets * s3:ListBucket * s3:GetBucketLocation * s3:GetObjectAcl * s3:DeleteObject * s3:PutObjectAcl * s3:PutObject #### Getting started When you create a new Environment in the Deployments section you will be presented with a list of available server types that you can add to the environment: You can add multiple servers to the same environment, enabling you to deploy to various server types at once. For example, you may have both an SFTP and an Amazon S3 server in your Production environment. This way you can deploy static assets to Amazon S3, and everything else to your SFTP server. After selecting the Amazon S3 server type, you will be presented with the following form to enter your S3 settings: The form is quite straightforward. Here's a description of some of the fields: * Access Key, Secret Key — you can grab your keys on the Security & Credentials page in your Amazon Web Services account portal. * Bucket — the name of a valid existing bucket. If you don't have any buckets yet, log in to the S3 console and create one. * Remote path — points to a directory inside your bucket where you wish to deploy files from your repository. * Use Reduced Redundancy Storage — optional setting. Read our [help article](//support.deploybot.com/article/92-using-reduced-redundancy-storage-with-s3) on that matter. Once you're done with the form and click Check Connection, DeployBot will verify your AWS keys and make sure that your bucket exists. After that, you will be presented with the optional settings and ability to turn on [CloudFront Invalidation](//support.deploybot.com/article/54-invalidate- cloudfront-distribution). --- Title: Shopify Integration Url: https://support.deploybot.com/deployment-integrations/shopify-integration --- [Shopify](http://shopify.com) integration in DeployBot is a great way to streamline the development, review, and deployment of your store themes. It also greatly simplifies the process of managing multiple themes at the same time and keeping track of updates going to many stores. > Just wanted to let you know that starting October 19, 2023, Shopify has > announced that they are revoking the API tokens created by the Shopify OAuth > application. It seems like apps designed for and marketed to developers are > no longer allowed and won't pass the review process. > > If you still integrate with Shopify via OAuth, make sure to change the > authorization method from OAuth to access token. Otherwise, your Shopify > integrations will soon stop working (see below). ## Setting up deployment to Shopify theme from an existing repository If you already have a repository in your account that has a Shopify theme and you want to be able to deploy it through DeployBot, here we will describe how you can do it. Start by creating a new deployment environment in the Deployments tab or use an existing environment. Once the environment is created, you can add a new server of "Shopify Theme" type and you should see the following screen (part of the page is shown): On that page you can enter a name of a server and your store details. You have an option of automatic or API key based authentication to Shopify. After you integrate with the store you can select either an existing theme or create a new one in your store, and that's where we will deploy the files. **Troubleshooting Shopify** ## How do I get the API Key and Admin API Access Token? You can find this information here: . But, here it's the walk-trough: First, create a Development App within your Shopify Store (Test App): 1. Click on **Develop Apps** , and then **Create an App:** Test App 2. In the configuration tab, the required privileges are: **write_themes, read_themes, write_online_store_pages, read_online_store_pages.** 3. Finally, the keys that you need are here: ## Why are some of the files I deploy are ignored? Shopify is very restrictive in what it accepts as theme files; only certain directories and files are allowed to be stored in a theme. Every file or directory that does not fit the pattern accepted by Shopify will be ignored and reported as such in the log. ## My deployment fails on the same file. Why? Please check if the file contains broken unicode characters. One good way to test if something is wrong with the file is to try to upload it manually to your theme through the Shopify interface and see if it works there. If it works there, but not in DeployBot, please contact our support to investigate the issue. ## Shopify it's rejecting one of my files? Shopify will perform a validation over the .liquid files, and if there is an issue on it, it will stop the deployment. You will have to fix the issue in the file (which you can discover in the log viewer), and then try again. The check is done on Shopify side and it does nothing to do with DeployBot. ## Why are my Shopify deployments are failing? The DeployBot Shopify App was deprecated due to some changes in the API. Because of that, the credentials should be entered manually as explained above. --- Title: Managing shared files and directories with atomic deployments Url: https://support.deploybot.com/deployment-integrations/managing-shared-files-and-directories-with-atomic-deployments --- DeployBot’s atomic deployments are a great tool to ensure that your application updates with zero downtime. This unique property is made possible by storing each release in a separate directory and then just re-pointing your web server to the updated version. But what if you want your released copies to share some common resources? For example, the files your users uploaded, or application logs. This is where the `shared` directory comes into the play. Paired with [symbolic links](https://en.wikipedia.org/wiki/Symbolic_link), it makes for the ultimate solution to this problem. For every shared directory you might have, simply add the following commands to the post-upload part of your deployment process: ``` ln -s $SHARED/ $RELEASE/ ``` **Note:** Don’t forget to replace `` and `` with paths to your source and target files (or directories). Keep in mind that all these files must exist in the shared directory for symbolic links to work properly. Because of that, you might want to auto- create directories with `mkdir -p $SHARED/` and files with `touch $SHARED/`. Both of these commands are safe to run on every deployments to ensure that the linked files are still present. **Example script** ``` # Create and link a directory mkdir -p $SHARED/avatars; ln -s $SHARED/avatars $RELEASE/wp-content/avatars # Create andk a file touch $SHARED/application.log; ln -s $SHARED/application.log $RELEASE/lopplication.log ``` --- Title: FTP deployments to Amazon EC2 instances Url: https://support.deploybot.com/deployment-integrations/ftp-deployments-to-amazon-ec2-instances --- If you are using DeployBot's deployment tools to deploy files to an Amazon EC2 instance through FTP, you may experience slow speed and performance. This can be due to the AWS firewall blocking ports necessary for passive FTP mode. To fix this, we recommend reading [this article](https://technoracle.com/how- to-setup-ftp-on-aws-ec2-ubuntu-instance/), which explains how to install an FTP server and open up the proper ports. _Important: If you use IP restrictions in your group policy, you must add our[full list of IPs found here](//support.deploybot.com/article/854-ips-and- ports-for-firewall-setup)._ --- Title: Invalidate CloudFront Distribution Url: https://support.deploybot.com/deployment-integrations/invalidate-cloudfront-distribution --- DeployBot can invalidate your CloudFront distribution after every deployment when using Amazon S3 deployments. This ensures that Amazon CloudFront servers always have the most recent content. If you have not already, you can read about deploying to Amazon S3 in a separate [help article](/article/874-deploying-static-sites-to-amazon-s3). **Cloudfront permissions we support:** * cloudfront:CreateInvalidation * cloudfront:GetDistribution #### How to invalidate CloudFront distribution If you use DeployBot to deploy files to an S3 bucket, and you also use that bucket as an origin for your CloudFront Distribution, you can use the CloudFront Invalidation feature in DeployBot to automatically invalidate that distribution. When setting up an Amazon S3 deployment in DeployBot, specify a valid CloudFront distribution ID in the server settings: DeployBot will take care of the rest. After each deployment it will send a list of changed files to invalidate to your CloudFront distribution. If you'd prefer to always invalidate the entire distribution, please enable the according checkbox. Invalidating files ensures that your CDN always serves the latest versions of your files. After the invalidation was initiated by DeployBot you can track its progress in the CloudFront Management Console. --- Title: Rackspace Cloud Sites Url: https://support.deploybot.com/deployment-integrations/rackspace-cloud-sites --- With DeployBot's FTP and SFTP deployment tools, it is very simple to deploy to any server with a simple click. With Rackspace Cloud Sites, the process of setting up a server makes it even easier. Here's a quick tour on how to get up and running with DeployBot deployments and Rackspace Cloud Sites. ## Creating a new site on Rackspace Cloud If you don't have an account already, go ahead and create one at [rackspacecloud.com](http://rackspacecloud.com). Once the account is set up, navigate to the **Hosting > Cloud Sites** link on the left side. Setting up a new site is easy. Just provide the domain name and follow the steps. The full process is documented in their [ knowledge base](http://www.rackspace.com/knowledge_center/article/getting-started-with- cloud-sites-2-1-how-to-add-a-new-website). Once the server is ready, you can proceed with setting up the deployment settings on DeployBot. ## Creating a new deployment server on DeployBot To create a new deployment server, go to the repository that you want to deploy and click on the **Deployments** tab. You should see a button to **Create Environment & Server** if you have not already. Follow the steps for creating an environment and then server. When you get to the **Server Settings** step, it should look something like this: The fields you want to pay attention to are: * **Repository Path:** The path to your repo on DeployBot where files will be deployed from. * **Server:** This is the IP address of the "ftp.domain.com" under the Domain tab in your Rackspace account. * **Remote path:** The default is `/your.domain.com/web/content" for Rackspace Cloud Sites. * **Login/Password:** This is the username/password for your Rackspace Cloud Sites account. If everything is correct, you should be able to click continue and see a message that the server was set up successfully. From this point forward, you can manually or automatically deploy to your Rackspace Cloud Site. --- Title: Using Reduced Redundancy Storage with S3 Url: https://support.deploybot.com/deployment-integrations/using-reduced-redundancy-storage-with-s3 --- DeployBot supports the Reduced Redundancy Storage (RRS) option when deploying to Amazon S3. If you have not already, you can read about deploying to Amazon S3 in a separate [help article](//support.deploybot.com/article/85-deploying- static-sites-to-amazon-s3). When setting up an Amazon S3 server in DeployBot, under the Advanced Options section you have an option to enable Reduced Redundancy Storage option. This will force DeployBot to send all files to your Amazon S3 bucket with that setting turned on. It can save you money in the long run when storing assets that are easily replaceable, such as thumbnails for images. Please note that enabling RRS for a server to which you have deployed before will not affect the files that were already uploaded to the bucket. For this reason DeployBot will ask you if you want to deploy from scratch after you enable the RRS option. Deploying from scratch in that case will enable RRS for existing files in your bucket. To find out more about RRS, check the [official documentation](http://aws.amazon.com/s3/faqs/#What_is_RRS). --- Title: Rackspace Cloud Files Url: https://support.deploybot.com/deployment-integrations/rackspace-cloud-files --- DeployBot supports deployments to [Rackspace Cloud Files](http://www.rackspace.com/cloud/public/files/) – an easy-to-use online storage for files and media. DeployBot can upload files from your Git repository to your Rackspace Cloud Files either automatically on every push, or manually. ## Getting started When you create a new Environment in the Deployments section you will see a list of available server types that you can add to that Environment: You can add multiple servers to the same environment, enabling you to deploy to various server types at once. For example, you may have both an SFTP and a Cloud Files server in your Production environment. After selecting the Cloud Files server type, you will be presented with the following form to enter your Cloud Files settings: The form is quite straightforward. Here's a description of some of the fields: * Username, API Key — you can grab your username and API keys in your Rackspace Cloud Account settings. * Container — the name of container in the Cloud Files account. If you don't have a container yet, DeployBot will create it for you automatically during deployment. * Remote path — points to a directory inside your Container where you wish to deploy files from your repository. * Country — country where your Rackspace account is created. * Region — data center where you want your files to be stored. Once you're done with the form, DeployBot will verify your credentials and make sure that your Container exists in the account. After that you will be presented with some optional settings, like excluding some of the files from deployment. The only thing left to do is deploy your files! --- Title: Purge Cache on Cloudflare Url: https://support.deploybot.com/deployment-integrations/purge-cache-on-cloudflare --- DeployBot can invalidate your Cloudflare cache after each deployment thanks to a new integration, which is currently in Beta. This ensures that Cloudflare servers always have the most recent content. **In the Cloudflare integration we support:** * Purge everything #### How to invalidate **Cloudflare** cache 1. First thing would be to enable the Beta features, in the settings menu. 2. Then, you can add the integration in the Integrations tab, using your [API Key](https://dash.cloudflare.com/profile/api-tokens): 3. After that, you will be able to trigger the action on the environment settings (you will also need to select the DNS zone): DeployBot will take care of the rest. After each deployment it will invalidate the entire distribution, making sure that everything it's removed from the cache. Invalidating files ensures that your CDN always serves the latest versions of your files. After the invalidation was initiated by DeployBot you can track its progress in the [Cloudflare Console](https://dash.cloudflare.com/). --- Title: Tracking releases with Sentry Url: https://support.deploybot.com/deployment-integrations/tracking-releases-with-sentry --- Using the Sentry integration, it is possible to send a notification to the 'Releases' section in any Sentry project once a deployment is completed. For further details on Sentry, kindly go to their [website](https://sentry.io/). **It's important to note** that Deploybot's current implementation with Sentry creates [a new Release](https://docs.sentry.io/api/releases/create-a-new- release-for-an-organization/). This means that, currently, Sentry _can_ be set up for specific projects, but it _can't_ be set up for specific environments inside specific projects. #### How to notify releases to Sentry? 1. First thing would be to enable the Beta features, in the settings menu. 2. Then, you can add the integration in the Integrations tab, in there you will have to enter your organisation name and the [authentication token](https://docs.sentry.io/api/guides/create-auth-token/#create-an-internal-integration): 3. After that, you will be able to trigger the action on the environment settings (you will also need to select the project): ### Required permissions for Sentry The following permissions should work for most workloads: Happy releasing! --- Title: Scheduling Deployments Url: https://support.deploybot.com/deployment-integrations/scheduling-deployments --- [DeployBot](https://www.deploybot.com) provides you with the flexibility not only to initiate a deployment manually or automatically when there's a new push, but also to schedule a deployment to execute at a future time. This feature can be particularly advantageous for testing environments. For instance, you might want to plan a deployment to your testing site later in the day, preparing it for a review. Alternatively, you could establish a recurring deployment schedule to implement any modifications pushed to your testing site at the week's conclusion. ## Scheduling a deployment Within DeployBot, you'll be able to choose from a number of different options when scheduling deployments to fit a wide variety of scenarios. To set up a scheduled deployment, simply navigate to your environment settings, and then you will have the option: Schedules (currently in Beta, but it will be released to production soon): Once you click on Schedule, you will then be presented with a number of schedule options to select and configure. Once one has been chosen, you can simply click **Save Changes** as normal and the schedule will be saved. Some notes about this: * The description is the schedule name, so you can identify it later on, * The Interval defines how often the deployment should run, using a [contab syntax](https://crontab.guru/) for now, for example @daily, or @weekly, * The Message it's the deployment message that will be included in the deployment, and the commit is the one that should be deployed: HEAD, will always take the last one, * Then you can also select to trigger notifications, and if you want the deployment to be from scratch or not Once the schedule is created, your deployments are going to be triggered automatically based on those settings. Happy deploying! 🚀 --- Title: My AWS S3 deployment fails Url: https://support.deploybot.com/deployment-integrations/my-aws-s3-deployment-fails --- Sometimes, the AWS S3 deployment fails because of **AccessControlListNotSupported** : The bucket does not allow ACLs. In order to solve this issue, we should: * Navigate to the Permissions tab of your S3 bucket. * Click `Edit` next to `Block public access` . * Uncheck `Block new public ACLs and uploading public objects` and `Remove public access granted through public ACLs` . * Click `Save` Then, retry the deployment on DeployBot, and everything should be OK. If after doing this, we receive the very same error, you can contact us at [support@deploybot.com](mailto:support@deploybot.com) 🙂 --- Title: Priority Deployments Url: https://support.deploybot.com/deployment-integrations/priority-deployments --- DeployBot's priority deployments feature is a powerful tool available exclusively for Premium plan subscribers. With priority deployments, you can ensure that specific deployments take precedence over others, enabling you to meet critical deadlines and handle urgent fixes efficiently. The option to enable priority deployments is activated by default for all deployments on the Premium plan. ## What are Priority Deployments? Priority deployments allow you to assign an elevated priority level to certain deployments in your workflow. When a deployment is tagged as a priority deployment, it gets special treatment within the DeployBot system, ensuring that it is processed ahead of other non-priority deployments in the queue. ## Key Benefits of Priority Deployments By utilizing priority deployments, you can experience several benefits, including: 1. **Faster Turnaround Time:** Priority deployments are processed before non-priority deployments, allowing important changes to be deployed more quickly. This ensures that time-sensitive updates or critical bug fixes are delivered promptly to users. 2. **Efficient Resource Allocation:** DeployBot intelligently allocates resources to prioritize priority deployments, ensuring that adequate server capacity and computing resources are available to handle them promptly. This reduces potential bottlenecks in your deployment pipeline. 3. **Improved Project Management:** By assigning priority levels to deployments, you gain better control over your project's timeline. You can effectively manage critical tasks, meet deadlines, and address urgent issues promptly. ## How to Use Priority Deployments To use priority deployments in DeployBot, follow these steps: 1. **Subscribe to the Premium Plan:** Priority deployments are available exclusively for DeployBot Premium plan subscribers. If you are currently on a different plan, upgrade to the Premium plan to access this feature. 2. **Tagging Deployments as Priority:** With the Premium plan, priority deployments are automatically activated for all deployments by default. Every deployment is treated as a priority deployment unless otherwise specified. ## Limitations It's important to note the following limitations of priority deployments: * Priority deployments are only available in DeployBot's Premium plan. * DeployBot will prioritize processing priority deployments, but their actual deployment time also depends on various factors like server load, network conditions, and deployment complexity. * While all deployments are considered priority deployments by default on the Premium plan, excessive use of priority deployments may impact the performance of non-priority deployments, as resources are allocated accordingly. ## Conclusion Priority deployments in DeployBot's Premium plan provide you with the ability to expedite crucial changes and address urgent issues promptly. By utilizing this powerful feature, you can improve your project's efficiency, meet deadlines consistently, and deliver a better experience to your users. Upgrade to the Premium plan today to unlock the benefits of priority deployments in DeployBot, where all deployments are treated as priority deployments by default. --- Title: Tracking deployments with Rollbar Url: https://support.deploybot.com/deployment-integrations/tracking-deployments-with-rollbar --- Using the Rollbar integration, it is possible to send a notification to the 'Deploy' section in any Rollbar project once a deployment is completed. For further details on Rollbar, kindly go to their [website](https://rollbar.com/). #### How to notify releases to Rollbar? 1. First thing would be to enable the Beta features, in the settings menu. 2. Then, you can add the integration in the Integrations tab, in there you will have to enter your [account access token](https://rollbar.com/settings/accounts/deploybot-test/access_tokens/): 3. After that, you will be able to trigger the action on the environment settings (you will also need to select the project): Happy deploying! --- Title: My newest commits are not visible Url: https://support.deploybot.com/troubleshooting/my-newest-commits-are-not-visible --- _There are a few of things to check if your most recent Git commits are not appearing in DeployBot, or if your repository branches are not appearing in your branch list in DeployBot._ ### _When Deploying_ _From the DeployBot dashboard or the repository overview page select the “Deploy” option. On the New Deployment page there is a refresh icon in the top right. This will pull in the most recent commit._ ### _Refresh Repository_ _Navigate to the repository where you’re wanting to refresh the commits. Once there, select "Settings” in the repository header. From the settings page go to the “Webhooks & Badges” page. The top section will include the webhook that makes automatic deployments possible. Copy the webhook URL and configure the webhook URL in your version control service._ _**Please note:**__For the refresh repository webhook to work, the repository key should be authorized to clone from your repository._ ### _Reconnecting Your Repository_ _Navigate to the repository where you’re wanting to refresh the commits. Once there, select "Settings” in the repository header. From the settings page go to the “Webhooks & Badges” page. In the “General Details" section there is a "New commits not appearing?” header. From there, click on the “reconnecting your repository” link. This will add our deployment key and refresh your repository settings._ _**Please note:**__If your repository is self-hosted or he OAuth connection used to connect that repository has been removed the reconnecting feature will be unavailable. You will have to manually verify the webhook and key are setup correctly._ _If you're having issues getting your most recent commits to appear, please don't hesitate to contact_[ _our support_](mailto:support@deploybot.com) _. We are always glad to help._ --- Title: Cannot connect to ubuntu 22.04 Url: https://support.deploybot.com/troubleshooting/cannot-connect-to-ubuntu-22-04 --- key type ssh-rsa not in PubkeyAcceptedAlgorithms If you are encountering the error "key type ssh-rsa not in PubkeyAcceptedAlgorithms" while attempting to connect to an SSH server with public key authentication, there is no need to worry. This error usually occurs when you are connecting to a server with a newer operating system such as **Ubuntu 22**. The reason for this error is that the SHA RSA 1 algorithm used for key generation by DeployBot is no longer supported in newer Linux systems. Fortunately, you can easily resolve this issue by adding the following line to `/etc/ssh/sshd_config` : ``` PubkeyAcceptedAlgorithms +ssh-rsa ``` After adding this line, you will need to restart the SSH service. Once you have done this, any SSH connections with that key type will be accepted. We hope this information helps you resolve the issue and secure your SSH connections. If you have any further questions or concerns, please do not hesitate to reach out to us. ### Allow Password Authentication from certain IPs The other option would be to change the file `etc/ssh/sshd_config` again, and allow password authentication but only for certain IPs, which we will whitelist, like this: ``` PasswordAuthentication no Match Address 192.168.1.0/24 PasswordAuthentication yes Match Address 2001:470:1f0b:915::/64 PasswordAuthentication yes ``` DeployBot IPs can be found here: [https://support.deploybot.com/article/96-ips-and-ports-for-firewall- setup](//support.deploybot.com/article/96-ips-and-ports-for-firewall-setup) ### Disable EC2 Instance Connect on AWS If you are using an instance on AWS, something that it was causing some issues was that the SSH keys are checked against another file (ec2-instance- connect/eic_run_authorized_keys), so it should be disabled to avoid issues. More info here: --- Title: I can't deploy to a SSH or SFTP server Url: https://support.deploybot.com/troubleshooting/i-can-t-deploy-to-a-ssh-or-sftp-server --- There are several things you can check when you are having problems deploying to your SSH or SFTP server. Here are some of them: #### If you are using public key authentication, try with login based authentication instead. This will allow you to see if the problem is related to the public key you've added. #### Check permissions on your ~/.ssh/authorized_keys file. Make sure that the authorized_keys file is located in home directory of a user you're using to setup deployments, and that the permissions on it are set to 0600. You can set the correct permissions for the file with this command: ``` chmod 0600 ~/.ssh/authorized_keys ``` #### Check that the key you downloaded from DeployBot is properly inserted in the authorized_keys file. Each key in the authorized_keys file should be on a separate line, in this format: ``` ssh-rsa AAAAB3...long-key-here...hUIo6uTLn staging-deployments@deploybot.com ssh-rsa AAAAB3...long-key-here...7bSkeiFdQ production-deployments@deploybot.com ``` #### Check your SSH log files. You should be able to find error messages related to the deployment attempt in one of these files: **/var/log/messages** , **/var/log/secure** , **/var/log/auth.log** or similar, depending on your OS version. #### Check MaxAuthTries option in your sshd_config file. You can find your **sshd_config** file in **/etc/sshd_config** , **/etc/ssh/sshd_config** or a similar location. **MaxAuthTries** should be set to a value no less than **5**. This is required since we have different levels of keys on our side, and we may provide more than one key for the authorization. --- Title: Permissions required to access a GitHub organization repository Url: https://support.deploybot.com/troubleshooting/permissions-required-to-access-a-github-organization-repository --- When connecting DeployBot to a GitHub organization repository it is necessary to enable third-party access to GitHub; by default third-party access is disabled. Only a GitHub organization owner has the ability to enable third- party access. To enable DeployBot to access your organization repository, go to your organization homepage in GitHub. Browse to the **Settings** tab for your organization, then choose **OAuth application policy** from the Settings sidebar (Third-party Access section). Under “Third-party application access policy”, click the “Remove restrictions” button. A prompt will appear to remove restrictions, click "Yes, remove application restrictions”. DeployBot will now be able to connect to your GitHub organization's repository. If you're having issues getting your GitHub organization repository connected to DeployBot, please don't hesitate to [contact our Support team](mailto:mailto:support@deploybot.com). We are always glad to help. --- Title: How should I handle deployments with Submodules? Url: https://support.deploybot.com/troubleshooting/how-should-i-handle-deployments-with-submodules --- DeployBot supports deploying repositories with submodules. Here are a couple of factors to consider when using submodules. ### Submodules linking to a private repository * When connecting to a submodule that’s in a private repository, the submodule needs to connect to the repository via SSH. * If your submodule is in a private repository, you will need to add DeployBot’s public SSH key for the repository. The key only needs read-only permissions. To find the SSH key, go to the settings page for your repository in DeployBot. ### Create a dedicated deployment user It’s good practice to create a dedicated user for deployments with submodules. This user would have the DeployBot public SSH key for submodules associated with it and only have access to necessary repositories. A dedicated user will resolve many common permission issues with submodules. If you’re a GitHub user, visit [GitHub to learn more about their recommendations for dedicated users](https://developer.github.com/guides/managing-deploy-keys/#machine- users). --- Title: hmac_client algorithm issue Url: https://support.deploybot.com/troubleshooting/hmac-client-algorithm-issue --- HMAC (Hash-based Message Authentication Code) is a widely-used algorithm for verifying the authenticity of messages between parties in a communication system. However, there are times when users might encounter issues with HMAC, specifically with the HMAC client algorithm. In this article, we will discuss the common causes and solutions for the HMAC client algorithm issue. **What is HMAC client algorithm issue?** The HMAC client algorithm issue is a problem that occurs when the client's HMAC algorithm doesn't match the server's HMAC algorithm. The client and server use HMAC to authenticate messages between them. If the client and server are not using the same algorithm, the authentication process will fail, and the message will not be delivered. **Common causes of the HMAC client algorithm issue** 1. Outdated software: One of the most common causes of the HMAC client algorithm issue is outdated software. If the client or server is running an older version of the software, it may not support the latest HMAC algorithms. 2. Misconfiguration: Another possible cause of the HMAC client algorithm issue is a misconfiguration. If the client and server are not configured correctly, the HMAC algorithm used by the client may not match the algorithm used by the server. 3. Network errors: Network errors can also cause the HMAC client algorithm issue. If there is a problem with the network connection between the client and server, the message may not be delivered, and the authentication process may fail. 4. Security protocols: Security protocols used by the client and server can also affect the HMAC algorithm used for authentication. If the client and server are using different security protocols, it can lead to the HMAC client algorithm issue. **Solutions for the HMAC client algorithm issue** 1. Update software: If the HMAC client algorithm issue is caused by outdated software, the solution is to update the software on both the client and server. This will ensure that both parties are using the latest HMAC algorithms. 2. Check configuration: If the issue is caused by misconfiguration, the solution is to check the configuration settings on both the client and server. Make sure that both parties are using the same HMAC algorithm and that the settings are configured correctly. 3. Troubleshoot network: If the issue is caused by network errors, the solution is to troubleshoot the network connection between the client and server. Check the network settings, and if necessary, reset the network connection. 4. Check security protocols: If the issue is caused by security protocols, the solution is to check the security protocols used by both the client and server. Make sure that both parties are using the same security protocols and that they are configured correctly. **Conclusion** The HMAC client algorithm issue can be a frustrating problem to deal with, but it's not an insurmountable one. By following the solutions outlined in this article, you can resolve the issue and ensure that your client and server are using the same HMAC algorithm for authentication. Remember to always keep your software updated, check configuration settings, troubleshoot network errors, and ensure that security protocols are correctly configured. **hmac_client algorithm issue on Deploybot** If after that the issue persist, the only way to resolve this is to enable an algorithm that's supported by DeployBot, on your hosting provider's end. The most secure MAC supported by DeployBot would be hmac-sha2-512. **How to do it?** Well, then make sure that you have the following MACs in your **/etc/ssh/sshd_config** file: ``` MACs umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,**hmac-sha2-512** ``` --- Title: Troubleshooting FTPS Issues Url: https://support.deploybot.com/troubleshooting/troubleshooting-ftps-issues --- In this guide, we will discuss common causes of FTPS deployment issues in DeployBot and how to resolve them. FTPS is a secure version of FTP that uses TLS to encrypt communications. However, like other methods, FTPS deployments may occasionally encounter problems. ## Common FTPS Issues 1. **Connection Problems:** If DeployBot can't connect to the FTP server, the issue might be due to incorrect address, username, or password, firewall settings, or server down times. 2. **Directory Issues:** DeployBot might fail to find the specified directory if the provided path is incorrect. 3. **Permission Problems:** If DeployBot doesn't have the necessary permissions to upload, delete or modify files, it will fail to deploy successfully. 4. **Data Transfer Issues:** If the data transfer process over FTPS is not successful, the deploy process will fail. ## Troubleshooting Steps **Note:** Remember to always back up your data before making any changes to your FTPS server or DeployBot settings. ### Step 1: Verify FTPS Server Details Ensure that you are using the right server address, port number, username, and password. Remember that FTPS uses port 990 by default, unlike FTP which uses port 21. ### Step 2: Check Firewall & Network Settings Firewalls can block your FTPS connection. Ensure that port 990 (FTPS) is allowed through your firewall. If you're unsure about how to do this, you'll need to contact your network administrator or consult your firewall's documentation. Do not forget to [whitelist DeployBot IPs](https://secure.helpscout.net/docs/5a2560f22c7d3a71c72bf35c/article/5a2986a02c7d3a1a640cb32e/). ### Step 3: Verify Directory Path Ensure that the directory path entered into DeployBot is correct. The path must be relative to the home directory of the FTP user. If the directory doesn't exist, ensure that DeployBot has the necessary permissions to create directories. ### Step 4: Confirm User Permissions Make sure that your FTP user has the necessary permissions to read, write, and delete files in the specified directory. Test these permissions manually if required. ### Step 5: Inspect Server Logs If you're still experiencing issues after checking the above, look at your FTP server logs. They can provide valuable insights into why your deployment failed. Key things to look for in the logs include unsuccessful authentication attempts, permission errors, and network errors. ### Step 6: Ignore SSL certificate errors Sometimes there are errors while trying to open a new SSL connection, either because the certificate it's expired or invalid. If that's the case, then you should enable the following option and try again: ## Contacting Support If you've gone through these steps and are still experiencing issues, please don't hesitate to reach out to our support team. When contacting support, please provide: 1. The error message you're seeing. 2. The troubleshooting steps you've already taken. 3. As much detail about your FTPS server and the deployment process as possible. Our team will be happy to help you resolve your FTPS deployment issues. Remember, the more details you can provide, the quicker we can help you solve your problem! --- Title: Adding SSH Keys into Github, Gitlab or Bitbucket Url: https://support.deploybot.com/troubleshooting/adding-ssh-keys-into-github-gitlab-or-bitbucket --- When working with Git repositories hosted on platforms like GitHub, Bitbucket, or GitLab, you may need to authenticate yourself to access your repositories. One way to do this is by using SSH keys, which are a secure way to connect to your repositories without having to enter your username and password each time. Here's how to add an SSH key to your GitHub, Bitbucket, or GitLab account: ## GitHub 1. Open your terminal and generate a new SSH key by running the following command: ``` ssh-keygen -t rsa -b 4096 -C "your_email@example.com" ``` 1. Note: Replace `your_email@example.com` with the email address associated with your GitHub account. 2. Press `Enter` when prompted to accept the default location for your SSH key. 3. Enter a passphrase for your SSH key when prompted, or leave it blank if you don't want to use one. 4. Open the `id_rsa.pub` file in your terminal or text editor and copy the contents of the file. 5. In your GitHub account, click on your profile picture in the top-right corner, and then click "Settings." 6. Click "SSH and GPG keys" in the left sidebar. 7. Click the "New SSH key" button. 8. Give your SSH key a title and paste the contents of your `id_rsa.pub` file into the "Key" field. 9. Click the "Add SSH key" button. ## Bitbucket 1. Open your terminal and generate a new SSH key by running the following command: ``` ssh-keygen -t rsa -b 4096 -C "your_email@example.com" ``` 1. Note: Replace `your_email@example.com` with the email address associated with your Bitbucket account. 2. Press `Enter` when prompted to accept the default location for your SSH key. 3. Enter a passphrase for your SSH key when prompted, or leave it blank if you don't want to use one. 4. Open the `id_rsa.pub` file in your terminal or text editor and copy the contents of the file. 5. In your Bitbucket account, click on your avatar in the bottom-left corner, and then click "Bitbucket settings." 6. Click "SSH keys" in the left sidebar. 7. Click the "Add key" button. 8. Paste the contents of your `id_rsa.pub` file into the "Key" field. 9. Give your SSH key a label and click the "Add key" button. ## GitLab 1. Open your terminal and generate a new SSH key by running the following command: ``` ssh-keygen -t rsa -b 4096 -C "your_email@example.com" ``` 1. Note: Replace `your_email@example.com` with the email address associated with your GitLab account. 2. Press `Enter` when prompted to accept the default location for your SSH key. 3. Enter a passphrase for your SSH key when prompted, or leave it blank if you don't want to use one. 4. Open the `id_rsa.pub` file in your terminal or text editor and copy the contents of the file. 5. In your GitLab account, click on your avatar in the top-right corner, and then click "Settings." 6. Click "SSH keys" in the left sidebar. 7. Paste the contents of your `id_rsa.pub` file into the "Key" field. 8. Give your SSH key a title and click the "Add key" button. That's it! You've successfully added an SSH key to your GitHub. **Please keep in mind that when using DeployBot, the SSH Key will be generated automatically, and the only thing that you might be asked would be to check if the key is added properly on the repository or not.** For more questions, you can reach us at [support@deploybot.com](mailto:support@deploybot.com) 🙂 --- Title: Missing packages or extensions from php containers Url: https://support.deploybot.com/troubleshooting/missing-packages-or-extensions-from-php-containers --- If you ever had issues like this one: ``` Verifying lock file contents can be installed on current platform. ``` ``` 0: 2023-12-06 10:05:35 am 12 ms output Your lock file does not contain a compatible set of packages. Please run composer update. ``` ``` 0: 2023-12-06 10:05:35 am 1 ms output Problem 1 ``` ``` 0: 2023-12-06 10:05:35 am 2 ms output - phpxmlrpc/phpxmlrpc is locked to version 4.8.1 and an update of this package was not requested. ``` ``` 0: 2023-12-06 10:05:35 am 2 ms output - phpxmlrpc/phpxmlrpc 4.8.1 requires ext-xml * -> it is missing from your system. Install or enable PHP's xml extension. ``` ``` 0: 2023-12-06 10:05:35 am 1 ms output Alternatively, you can run Composer with --ignore-platform-req=ext-xml to temporarily ignore these required extensions. ``` It means that there are missing extensions from your PHP Container. In the example, it's the php-xml extension. In order to install it, you will need to extend our container, and then install it, with the current command: ``` echo 'Installing php-xml extension'apt-get install php-xml ``` Or, something like this, in DeployBot web UI: Happy deploying! 🚀 --- Title: Fix SSH authentication errors Url: https://support.deploybot.com/troubleshooting/fix-ssh-authentication-errors --- Hi there! If you are encountering SSH public key authentication errors when using Deploybot, don't worry - there are some things you can check to resolve the issue. Here are some helpful steps to follow: First, when attempting to add a server to your project, you may receive a message stating that Deploybot couldn't access the server using the credentials provided, and asking if you've uploaded the appropriate public key onto the server. If you see this message, there are a few things you should check: 1. Make sure you've added the key from the following location within your project: [https://your-deploy-domain.deploybot.com/](https://your-deploy-domain.deploybot.com/projects/project_name/repository) 2. Check that the key has been added to **~/.ssh/authorized_keys** on your server, for your deployment user. 3. Make sure the permissions of the ~/.ssh directory and the authorized_keys file are set to 1. **drwx------ 8 testuser staff 256 21 Sep 14:00 /Users/testuser/.ssh** , 2. **rw------- 1 testuser staff 1211 21 Nov 16:29 /Users/testuser/.ssh/authorized_keys** , 4. respectively. If they're not, you can modify them using the following commands: 1. **$ chmod 700 ~/.ssh/** 2. **$ chmod 600 ~/.ssh/authorized_keys** Please note that if you're able to connect locally via your own public key pair, it's possible that your server accepts a different key format than what Deploybot generates, which is ED25519 on newer projects, or RSA on older projects. Currently, DeployBot only uses RSA keys. For additional information about SSH login failures, you can check your authorization log file, which is typically located within **/var/log/auth.log** on most Linux systems. To monitor this log while you test a connection from Deploybot, you can run the following command: **tail -f /var/log/auth.log**. You may need to update your LogLevel to a high enough verbosity as well, to ensure that useful information is provided when testing. This is normally configured within **/etc/ssh/sshd_config** and the line will look like so: LogLevel DEBUG. If you make any changes to the configuration, you'll likely need to restart the sshd process for it to take effect. I hope this information helps you resolve your issue! --- Title: Solving Net::FTPTempError: 421 issue Url: https://support.deploybot.com/troubleshooting/solving-net-ftptemperror-421-issue --- Lots of users have reported the following error while deploying applications using FTP: ``` Net::FTPTempError: 421-Sorry, cleartext sessions and weak ciphers are not accepted on this server. 421 Please reconnect using TLS security mechanisms. ``` We're glad to inform you that the **FTPS (File Transfer Protocol Secure)** service is already available on our platform. This feature will ensure secure and efficient file transfers to your servers. If you're interested in trying it out, we would be more than happy to assist you through the procedure. To get started: 1. Navigate to the servers section and create or select an existing server. 2. In the protocol dropdown, you will find the 'FTPS (Implicit SSL)' option. Select it. 3. Fill in your FTPS server details including host, port, username, and password. Remember, if you encounter any difficulties or have any further questions about this feature, our support team is always ready and willing to help. Which is just one click away. Feel free to reach out to us. We are excited for you to try out our new FTPS feature and looking forward to hearing about your experience. Happy deploying 🚀 --- Title: GitHub: Key is already in use Url: https://support.deploybot.com/troubleshooting/github-key-is-already-in-use --- When attempting to add a deployment key to a GitHub repository, such as in the case of needing access for a submodule, or fetching remote dependencies within your build pipeline, you may run into the following error: ``` Key is already in use ``` This is because your DeployBot project's public key has already been added to GitHub, most likely as the deployment key for the main repository you're trying to deploy. Github does have a restriction that only allows a deployment key to be used on a single repository, but they offer a solution whereby you can create a machine (non-human) user and assign the deployment key to that user, which will then be given access to multiple Github repositories. More information on this can be found in [Github's documentation](https://docs.github.com/en/authentication/connecting-to-github- with-ssh/managing-deploy-keys#machine-users). --- Title: Cannot build webpack application Url: https://support.deploybot.com/troubleshooting/cannot-build-webpack-application --- Sometimes, when trying to build webpack applications, we encounter errors like this one: ``` Module Error (from ./node_modules/sass-loader/dist/cjs.js): ``` ``` Unexpected token '?' ``` ``` ./public/assets/theme/sass/home.scss ``` If that's the case, the easiest solution would be to configure a custom container, with the latest node LTS version, by doing the following: 1\. In the containers section, create a custom container that references node:18.15.0: 2\. After that, we can use our custom container directly in our build step, like this: We hope this information helps you resolve the issue with webpack If you have any further questions or concerns, please do not hesitate to reach out to us. --- Title: Understanding Build Time in DeployBot Url: https://support.deploybot.com/troubleshooting/understanding-build-time-in-deploybot --- DeployBot is designed to streamline your deployment process, making it both efficient and reliable. An important aspect to consider during deployment is the time it takes to build your application. By default, DeployBot allows up to **30 minutes for a build to complete**. This is sufficient for most use cases and ensures that resources are allocated efficiently for all users. Incident screenshot ### When Would You Need More Than 30 Minutes? Some projects, particularly large or complex ones, may require more time for a successful build. This could be due to several factors, including but not limited to: * Large repositories with extensive histories or files. * Complex build processes that involve compiling code, running tests, or generating assets. * High dependency resolution times for package managers. ### Requesting Extended Build Time If you find that your deployments consistently take longer than 30 minutes, don’t worry! We understand that every project is unique. **You have the option to request an extension** on the build time limit. To request more time for your builds, simply reach out to our support team with the following information: 1. The name of your repository or project. 2. The average time your build process takes or an estimate of the time required. 3. Any relevant details about your build setup that may help us understand your needs. You can contact support through the following channels: * **Email** : Send a message to [support@deploybot.com](mailto:support@deploybot.com) * **Support Ticket** : Open a ticket through your DeployBot dashboard. We’ll review your request and work with you to find a solution that ensures your deployments run smoothly. ### Conclusion Our goal at DeployBot is to provide a seamless deployment experience. While the 30-minute default build time meets the needs of most of our customers, we are here to support your project's specific requirements. Don't hesitate to reach out if you need additional time for your builds. Our support team is ready to assist you in optimizing your deployment process. --- Title: Random failures when deploying multiple sites to WPEngine Url: https://support.deploybot.com/troubleshooting/random-failures-when-deploying-multiple-sites-to-wpengine --- Sometimes, when deploying multiple websites to WPEngine at the same time using SFTP, it might occasionally cause random errors. You can find more information about these errors [here](https://wpengine.com/support/troubleshooting-ssh- gateway-issues). From what we have observed, these issues occur when multiple connections are opened simultaneously, resulting in an error on our side: **IOError: closed stream**. WPEngine has taken measures to block these multiple connections, which unfortunately prevents the deployment from proceeding. If you are experiencing this issue, please don't hesitate to contact us at contact@deploybot.com. We can adjust some settings on your environments to ensure a sequential deployment, thereby resolving the issue promptly. --- Title: Deployment Permissions Url: https://support.deploybot.com/users-access/deployment-permissions --- DeployBot offers three levels of permissions on deployments that can be limited to specific repositories. Deployment permissions can be set by admins or account owners. The permissions can be set on the individual user account page. Permissions can also be set on the repository settings. ### Permissions for deployments are: **View Activity:** * View deployment history. * View deployment revision history for specific deployment. * Deploy only if automatic deployment is set for environment. **View & Deploy:** * All of the above, plus: * Initiate a deployment. * Retry a deployment. **Environment Access:** * All of the above but only for a specific environment. **Full Access:** * All of the above but for all environments, plus: * Add and edit servers/environments. * View deployment incidents. --- Title: How to Request a Migration from DeployBot to DeployHQ Url: https://support.deploybot.com/account-billing/how-to-request-a-migration-from-deploybot-to-deployhq --- DeployBot is now part of DeployHQ! This guide will walk you through the migration request process using our automated Migration Wizard, which streamlines the transition to DeployHQ's enhanced platform. **Overview** The Migration Wizard is a 4-step process that helps you transition from DeployBot to DeployHQ with minimal disruption. Most of your configurations will be migrated automatically, and our support team will guide you through any manual setup required. **Migration Process** Access the Migration Wizard from your DeployBot account: **Step 1** : Welcome & Overview Click "Start Migration Wizard" to begin. **Step 2** : Choose Migration Type Select the migration approach that fits your account size. **Step 3** : Review what will be handled automatically and what may require manual attention The following will be migrated automatically: * Repository links and branches * Server configurations (FTP, SFTP, SSH, S3, Heroku, Elastic Beanstalk, Digital Ocean) * Deployment scripts and commands * SSH keys and authentication * Config files (static files) * Pre-deployment and post-deployment commands * Build scripts and cached build commands * Excluded files * Server paths and credentials **Step 4** : Submit Migration Request This is the final step where you initiate the migration. **What Happens After Submission:** 1\. DeployHQ Account Creation * We automatically create your new DeployHQ account * You'll receive welcome email with login credentials * A support ticket is created for our team to track your migration 2\. Migration Execution * Repositories, servers, and deployment configurations are migrated * SSH keys are automatically configured * Server environments and groups are recreated in DeployHQ 3\. Testing & Verification * Test your deployments in DeployHQ * Complete any manual configurations with our guidance * Verify all settings match your requirements 4\. Transition Complete * Once satisfied with DeployHQ, you can cancel your DeployBot subscription * During migration, you only pay for your DeployBot account **Frequently Asked Questions:** **Can I still use my DeployBot account during migration?** Yes! You can continue using your DeployBot account without any interruptions until you're ready to make the full switch to DeployHQ. **Will I be billed on both platforms?** During the migration process, you'll only be billed for your active DeployBot account. Once migration is complete and confirmed, you can cancel your DeployBot subscription, and your DeployHQ account becomes your active billing account. **What if I need help?** You can contact our support team at any time during the migration process by clicking "Need Support?" in the wizard or emailing [support@deploybot.com](mailto:support@deploybot.com). **Can I pause and resume the migration?** Yes, the Migration Wizard allows you to pause and resume at any time. Your progress is saved as you complete each step. \--- Ready to migrate? Access the Migration Wizard from your DeployBot account dashboard and begin your transition to DeployHQ today! --- Title: How to Update Your Repository URL Url: https://support.deploybot.com/common-questions/how-to-update-your-repository-url --- If your repository has moved to a new location (e.g., transferred to a different workspace on Bitbucket, GitHub, or GitLab), you can update the URL in DeployBot without needing to recreate the project. ## Before You Start If your repository uses SSH key authentication, you'll need to add the DeployBot public key to your new repository or workspace: 1. In DeployBot, go to your repository's **Settings > General** page 2. Copy the **public key** shown there 3. Add it to your new repository host: * **Bitbucket** : Go to **Repository Settings > Access keys** and click **Add key** * **GitHub** : Go to **Repository Settings > Deploy keys** and click **Add deploy key** * **GitLab** : Go to **Repository Settings > Repository > Deploy keys** and click **Add key** 4. Paste the public key and save **Tip:** If multiple repositories in your DeployBot account share the same SSH key (account-level key), you only need to add it once at the workspace or organization level on your Git host, rather than adding it to each repository individually. For example, on Bitbucket, go to **Workspace Settings > Access keys** to add it as a workspace-wide key. ## Steps to Update the Repository URL 1. Log in to your DeployBot account 2. Go to **Repositories** and click the repository you want to update 3. Click the **Settings** tab to open repository settings 4. Under **General** , find the **Repository URL** section 5. Click **"Do you want to change this URL?"** 6. On the **Reconnect repository** page, select how you want to connect: * **GitHub** — select a connected GitHub account and choose the repository * **Bitbucket** — select a connected Bitbucket account and choose the repository * **GitLab** — select a connected GitLab account and choose the repository * **Others** — manually enter the repository URL for self-hosted or other Git providers 7. Click **"Reconnect"** ## Important Notes * You cannot reconnect a repository while a deployment is in progress. Wait for any active deployments to finish first. * Your server environments, deployment settings, and history will be preserved — only the source repository URL changes. * If new commits stop appearing after the change, go back to **Settings > General** and click **"reconnecting your repository"** to re-add the deployment key and webhook.