Servers inventory & deployment solution
Currently deep-deep alpha state.
Currently there's the way to configure the agent via environment variables:
BOOTLOADER_URL- URL of bootloader-web instance, default is
BROKER_URL- URL of broker for celery, default is
DB_HOST- Hostname of PostgreSQL database to use for the app, default is
DB_NAME- Database name, default is
DB_PASSWORD- Password to access the database, default is
DB_USER- Username to access the database, default is
DEFAULT_THEME- Theme name to use
<true|false>- Enable or disable proxying gravatar requests
SSL_CERTIFICATE_CONTENTS- contents of SSL certificates to use for HTTPS
<true|false>Enable SSL support
SSL_KEY_CONTENTS- contents of SSL private key to use for HTTPS
<true|false>enables redirect from HTTP to HTTPS
All the releases and development versions are represented as docker images
The most stable release
docker pull teran/bootloader-web:0.0.1-alpha1 docker pull teran/bootloader-agent:0.0.1-alpha1
The most recent build (dangerous, could be totally unstable)
docker pull teran/bootloader-web:latest docker pull teran/bootloader-agent:latest
Compatibility and guarantees
Current project state: Alpha
Pending release number: 0.0.1-alpha2
All releases will be reflected as a git tag.
Build for bootloader components would mean corresponding docker images.
The most recent build is always tagged with
latest no matter what version is it,
so it's just time-related tag.
Each branch have it's own tag, for
master git-branch it's
master tag in docker hub.
Eeach release gonna be tagged accordingly.
The most proper way for development purposes is to use
:master docker tag.
For testing and/or production - tag describes particular version.
Update procedure between versions is not designed at the moment.
But based on how application is developed it should work in proper way without any
The most stable current API version:
The latest dev API version:
Any incompatible changes will be marked as dedicated API version.
API Alpha versions
Their main purpose is to be a trade off between stability and development speed.
All of incompatible changes will be reflected in new version.
Supported during current version lifecycle only.
API Beta versions
Served for stabilization, i.e. fixes only are accepted.
Supported during current application version lifecycle only.
API Stable versions
A kind of LTS for API.
Supported during two stable releases.
API versions lifecycle
Normally it should work the following way:
v1alpha1 - the first initial version shows what could we need from API.
It will become
v1alpha2 as only it would have incompatible changes, i.e.
new fields/removed fields or changed data types.
In addition the most recent version of Alpha API will be forked to v1beta1 on first
alpha-release, and the most recent beta-version to stable on stable application release.
Legacy API versions could stay for some time for some reasons, but they are not going to be
supported or verified for compatibility.
- 3.6 (optional)
- 1.6 (optional)
- 1.7 (optional)
- 1.8 (optional)
- 1.9 (optional)
- 1.10 (optional)
This version list means bootloader-web tests against them but here are some "but":
- optional versions could be skipped if they're support would require too much
bootloader is licenced under GPLv2 licence.
However some parts of the software uses third-party code, here's the list of JS
libraries used in bootloader-web and their licenses:
- Bootstrap - Licensed under the MIT license
- html5shiv - MIT/GPL2 Licensed
- jQuery - http://jquery.org/license
- respond - Licensed under the MIT license
- BOOTSTRA.386 - Licensed under Apache-2.0 licence
- Slate theme - Lincenced under MIT licence
- Yeti theme - Lincenced under MIT licence
Alpha2 release features and requirements
- [X] Interactive progress bars for deployments in non-finite states
- [ ] One-click redeploy with "repeat" button
- [ ] Make deployment timeouts configurable from profiles
- [ ] Per-step timeouts for deployments
- [ ] Implement delete_file action on agent
- [ ] Errors are come to UI
- [ ] Queue tests
- [ ] Input validation with UI error displaying
- [X] Handle JS errors without alert()
- [ ] Update any object through WebUI
- [ ] Full REST API namespacing with properly namespaced tests
- [ ] App specific API access-tokens
- [ ] Metrics export(Prometheus format?)
- [ ] Liveness and readiness check handlers
- [ ] Slack and email notifications about deployments
- [ ] Profiles API namespacing
Beta1 release features and requirements
- [ ] All key parts are covered with tests
- [ ] All the pipelines are manually tested