Repository files navigation

Docker image for Keeweb

🔑 Keeweb Password Manager 🔑

The🔀 docker/keeweb branch contains the Keeweb password manager within a docker image, which allows you to host it withinDocker, instead of a bare-metal or local install.

• About
• Images
• Install
  • Docker Run
  • Docker Compose
  • Traefik Integration
    • Labels
    • Dynamic.yml
    • Static.yml
      • Providers
      • certificatesResolvers
      • entryPoints (Normal)
      • entryPoints (Cloudflare)
  • Authentik Integration
    • Labels
    • Dynamic.yml
• Env Variables & Volumes
  • Environment Variables
  • Volumes
• Shell / Bash
• SSL Certificates
• Logs
• Build
  • Before Building
    • LF over CRLF
    • Set+x / 0755 Permissions
  • Build docker/alpine-base Image
    • amd64
    • arm64 / aarch64
  • Builddocker/keeweb Image
    • amd64
    • arm64 / aarch64
    • Upload: hub.docker.com / ghcr.io / local
    • Image Tags
  • Extra Notes
    • Custom Scripts
    • Associated Workflows
      • deploy-docker-github-sync.yml
      • deploy-docker-github.yml
      • deploy-docker-dockerhub.yml

This repository contains Keeweb Password Manager, distributed within a docker image which can be deployed and utilized in your browser.

Use any of the following images in your📄 docker-compose.yml orrun command:

Service	Version	Image Link
Docker Hub		🔖 keeweb/keeweb:latest 🔖 keeweb/keeweb:1.19.0 🔖 keeweb/keeweb:1.19.0-amd64 🔖 keeweb/keeweb:1.19.0-arm64 🔖 keeweb/keeweb:development 🔖 keeweb/keeweb:development-amd64 🔖 keeweb/keeweb:development-arm64
Github		🔖 ghcr.io/keeweb/keeweb:latest 🔖 ghcr.io/keeweb/keeweb:1.19.0 🔖 ghcr.io/keeweb/keeweb:1.19.0-amd64 🔖 ghcr.io/keeweb/keeweb:1.19.0-arm64 🔖 ghcr.io/keeweb/keeweb:development 🔖 ghcr.io/keeweb/keeweb:development-amd64 🔖 ghcr.io/keeweb/keeweb:development-arm64

Instructions on using this container

If you want to bring the docker container up quickly, use the following command:

docker run -d --restart=unless-stopped -p 443:443 --name keeweb -v${PWD}/keeweb:/config ghcr.io/keeweb/keeweb:latest

Create a new📄 docker-compose.yml with the following:

services:keeweb:container_name:keewebimage:ghcr.io/keeweb/keeweb:latest# Github image# image: keeweb/keeweb:latest                  # Dockerhub imagerestart:unless-stoppedvolumes:            -./keeweb:/configenvironment:            -PUID=1000            -PGID=1000            -TZ=Etc/UTC

Our first step is to tell Traefik about our Keeweb container. We highly recommend you utilize a Traefikdynamic file, instead oflabels. Using a dynamic file allows for automatic refreshing without the need to restart Traefik when a change is made.

If you decide to uselabels instead of adynamic file, any changes you want to make to your labels will require a restart of Traefik.

We will be setting up the following:

• Amiddleware to re-direct http to https
• Aroute to access Keeweb via http (optional)
• Aroute to access Keeweb via https (secure)
• Aservice to tell Traefik how to access your Keeweb container
• Aresolver so that Traefik can generate and apply a wildcard SSL certificate

To add Keeweb to Traefik, you will need to open your📄 docker-compose.yml and apply the following labels to your Keeweb container. Ensure you changedomain.lan to your actual domain name.

services:keeweb:container_name:keewebimage:ghcr.io/keeweb/keeweb:latest# Github image# image: keeweb/keeweb:latest               # Dockerhub imagerestart:unless-stoppedvolumes:            -./keeweb:/configenvironment:            -PUID=1000            -PGID=1000            -TZ=Etc/UTClabels:#   General          -traefik.enable=true#   Router > http          -traefik.http.routers.keeweb-http.rule=Host(`keeweb.localhost`) || Host(`keeweb.domain.lan`)          -traefik.http.routers.keeweb-http.service=keeweb          -traefik.http.routers.keeweb-http.entrypoints=http          -traefik.http.routers.keeweb-http.middlewares=https-redirect@file#   Router > https          -traefik.http.routers.keeweb-https.rule=Host(`keeweb.localhost`) || Host(`keeweb.domain.lan`)          -traefik.http.routers.keeweb-https.service=keeweb          -traefik.http.routers.keeweb-https.entrypoints=https          -traefik.http.routers.keeweb-https.tls=true          -traefik.http.routers.keeweb-https.tls.certresolver=cloudflare          -traefik.http.routers.keeweb-https.tls.domains[0].main=domain.lan          -traefik.http.routers.keeweb-https.tls.domains[0].sans=*.domain.lan#   Load Balancer          -traefik.http.services.keeweb.loadbalancer.server.port=443          -traefik.http.services.keeweb.loadbalancer.server.scheme=https

After you've added the labels above, skip thedynamic.yml section and go straight to thestatic.yml section.

If you decide to not uselabels and want to use a dynamic file, you will first need to create your dynamic file. the Traefik dynamic file is usually nameddynamic.yml. We need to add a newmiddleware,router, andservice to our Traefik dynamic file so that it knows about our new Keeweb container and where it is.

http:middlewares:https-redirect:redirectScheme:scheme:"https"permanent:truerouters:keeweb-http:service:keewebrule:Host(`keeweb.localhost`) || Host(`keeweb.domain.lan`)entryPoints:                -httpmiddlewares:                -https-redirect@filekeeweb-https:service:keewebrule:Host(`keeweb.localhost`) || Host(`keeweb.domain.lan`)entryPoints:                -httpstls:certResolver:cloudflaredomains:                    -main:"domain.lan"sans:                          -"*.domain.lan"services:keeweb:loadBalancer:servers:                    -url:"https://keeweb:443"

These entries will go in your Traefikstatic.yml file. Any changes made to this file requires that you restart Traefik afterward.

Ensure you add the following new section to yourstatic.yml:

providers:docker:endpoint:"unix:///var/run/docker.sock"exposedByDefault:falsenetwork:traefikwatch:truefile:filename:"/etc/traefik/dynamic.yml"watch:true

The code above is what enables the use of adynamic file instead of labels. Change/etc/traefik/dynamic.yml if you are placing your dynamic file in a different location. This path is relative to inside the container, not your host machine mounted volume path. Traefik keeps most files in the/etc/traefik/ folder.

After you add the above, open your Traefik's📄 docker-compose.yml file and mount a new volume so that Traefik knows where your new dynamic file is:

traefik:container_name:traefikimage:traefik:latestrestart:unless-stoppedvolumes:            -/var/run/docker.sock:/var/run/docker.sock:ro            -/etc/localtime:/etc/localtime:ro            -./config/traefik.yml:/etc/traefik/traefik.yml:ro            -./config/dynamic.yml:/etc/traefik/dynamic.yml:ro

You must ensure you add a new volume like shown above:

• /config/dynamic.yml:/etc/traefik/dynamic.yml:ro

On your host machine, make sure you place thedynamic.yml file in a sub-folder calledconfig, which should be inside the same folder where your Traefik's📄 docker-compose.yml file is. If you want to change this location, ensure you change the mounted volume path above.

After you have completed this, proceed to the sectioncertificatesResolvers.

Open your Traefikstatic.yml file. We need to define thecertResolver that we added above either in your dynamic file, or label. To define thecertResolver, we will be adding a new section labeledcertificatesResolvers. We are going to use Cloudflare in this example, you can use whatever from the list at:

• https://doc.traefik.io/traefik/https/acme/#providers

certificatesResolvers:cloudflare:acme:email:youremail@address.comstorage:/cloudflare/acme.jsonkeyType:EC256preferredChain:'ISRG Root X1'dnsChallenge:provider:cloudflaredelayBeforeCheck:15resolvers:                    -"1.1.1.1:53"                    -"1.0.0.1:53"disablePropagationCheck:true

Once you pick the DNS / SSL provider you want to use from the code above, you need to see if that provider has any special environment variables that must be set. TheProviders Page lists all providers and also what env variables need set for each one.

In our example, since we are usingCloudflare fordnsChallenge ->provider, we must set the following environment variables:

• CF_API_EMAIL
• CF_API_KEY

Create a.env environment file in the same folder where your Traefik📄 docker-compose.yml file is located, and add the following:

CF_API_EMAIL=yourcloudflare@email.comCF_API_KEY=Your-Cloudflare-API-Key

Save the.env file and exit. For these environment variables to be detected by Traefik, you must give your Traefik container a restart. Until you restart Traefik, it will not be able to generate your new SSL certificates.

You can wait and restart in a moment after you finish editing thestatic.yml file, as there are more items to add below.

Finally, inside the Traefikstatic.yml, we need to make sure we have ourentryPoints configured. Add the following to the Traefikstatic.yml file only if youDON'T have entry points set yet:

entryPoints:http:address::80http:redirections:entryPoint:to:httpsscheme:httpshttps:address::443http3:{}http:tls:options:defaultcertResolver:cloudflaredomains:                    -main:domain.lansans:                          -'*.domain.lan'

If your website is behind Cloudflare's proxy service, you need to modify yourentryPoints above so that you can automatically allow Cloudflare's IP addresses through. This means your entry points will look a bit different.

In the example below, we will addforwardedHeaders ->trustedIPs and add all of Cloudflare's IPs to the list which are available here:

• https://cloudflare.com/ips/

http:address::80forwardedHeaders:trustedIPs:&trustedIps                -103.21.244.0/22                -103.22.200.0/22                -103.31.4.0/22                -104.16.0.0/13                -104.24.0.0/14                -108.162.192.0/18                -131.0.72.0/22                -141.101.64.0/18                -162.158.0.0/15                -172.64.0.0/13                -173.245.48.0/20                -188.114.96.0/20                -190.93.240.0/20                -197.234.240.0/22                -198.41.128.0/17                -2400:cb00::/32                -2606:4700::/32                -2803:f800::/32                -2405:b500::/32                -2405:8100::/32                -2a06:98c0::/29                -2c0f:f248::/32http:redirections:entryPoint:to:httpsscheme:httpshttps:address::443http3:{}forwardedHeaders:trustedIPs:*trustedIpshttp:tls:options:defaultcertResolver:cloudflaredomains:                    -main:domain.lansans:                          -'*.domain.lan'

Save the files and then give Traefik and your Keeweb containers a restart.

This section will not explain how to install and set upAuthentik. We are only going to cover adding Keeweb integration to Authentik.

Sign into the Authentik admin panel, go to the left-side navigation, selectApplications ->Providers. Then at the top of the new page, clickCreate.

^{Authentik: SelectApplications ›Providers}

^{Authentik: SelectCreate}

For theprovider, selectProxy Provider.

^{Authentik: Select desired provider type, or selectProxy Provider}

Add the following provider values:

• Name:Keeweb ForwardAuth
• Authentication Flow:default-source-authentication (Welcome to authentik!)
• Authorization Flow:default-provider-authorization-implicit-consent (Authorize Application)

SelectForward Auth (single application):

• External Host:https://keeweb.domain.lan

^{Authentik: Create newProvider}

Once finished, clickCreate. Then on the left-side menu, selectApplications ->Applications. Then at the top of the new page, clickCreate.

^{Authentik: SelectApplications ›Applications}

^{Authentik: SelectCreate}

Add the following parameters:

• Name:Keeweb (Password Manager)
• Slug:keeweb
• Group:Security
• Provider:Keeweb ForwardAuth
• Backchannel Providers:None
• Policy Engine Mode:any

^{Authentik: Create Application}

Save, and then on the left-side menu, selectApplications ->Outposts:

^{Authentik: SelectApplications ›Outposts}

Find yourOutpost and edit it.

^{Authentik: Edit outpost}

MoveKeeweb (Password Manager) to the right sideSelected Applications box.

^{Authentik: Assign application to outpost}

If you followed ourTraefik guide above, you were shown how to add your Keeweb container to Traefik using either the📄 dynamic file orlabels. Depending on which option you picked, follow that section's guide below.

• Forlabel users, go to the sectionLabels below.
• Fordynamic file users, go to the section📄 dynamic file below.

Open your Keeweb's📄 docker-compose.yml and modify your labels to include Authentik as amiddleware by addingauthentik@file to the labeltraefik.http.routers.keeweb-https.middlewares. You should have something similar to the example below:

services:keeweb:container_name:keewebimage:ghcr.io/keeweb/keeweb:latest# Github image# image: keeweb/keeweb:latest               # Dockerhub imagerestart:unless-stoppedvolumes:            -./keeweb:/configenvironment:            -PUID=1000            -PGID=1000            -TZ=Etc/UTClabels:#   General          -traefik.enable=true#   Router > http          -traefik.http.routers.keeweb-http.rule=Host(`keeweb.localhost`) || Host(`keeweb.domain.lan`)          -traefik.http.routers.keeweb-http.service=keeweb          -traefik.http.routers.keeweb-http.entrypoints=http          -traefik.http.routers.keeweb-http.middlewares=https-redirect@file#   Router > https          -traefik.http.routers.keeweb-https.rule=Host(`keeweb.localhost`) || Host(`keeweb.domain.lan`)          -traefik.http.routers.keeweb-https.service=keeweb          -traefik.http.routers.keeweb-https.entrypoints=https          -traefik.http.routers.keeweb-https.middlewares=authentik@file          -traefik.http.routers.keeweb-https.tls=true          -traefik.http.routers.keeweb-https.tls.certresolver=cloudflare          -traefik.http.routers.keeweb-https.tls.domains[0].main=domain.lan          -traefik.http.routers.keeweb-https.tls.domains[0].sans=*.domain.lan#   Load Balancer          -traefik.http.services.keeweb.loadbalancer.server.port=443          -traefik.http.services.keeweb.loadbalancer.server.scheme=https

If you opted to use the📄 dynamic file, open your Traefik's📄 dynamic.yml file and apply theauthentik@file middleware to look something like the following:

keeweb-https:service:keewebrule:Host(`keeweb.localhost`) || Host(`keeweb.domain.com`)entryPoints:                -httpsmiddlewares:                -authentik@filetls:certResolver:cloudflaredomains:                    -main:"domain.com"sans:                          -"*.domain.com"

After you've done everything above, give yourTraefik andAuthentik containers a restart. Once they come back up; you should be able to accesskeeweb.domain.lan and be prompted now to authenticate with Authentik. Once you authenticate, you should be re-directed to your Keeweb home screen which asks you to load a vault file.

This section outlines that environment variables can be specified, and which volumes you can mount when the container is started.

The following env variables can be modified before spinning up this container:

The following volumes can be mounted with this container:

By mounting the volume above, you should now have access to the following folders:

You can access the docker container's shell by running:

dockerexec -it keeweb ash

This docker image automatically generates an SSL certificate when the nginx server is brought online.

You may opt to either use the generated self-signed certificate, or you can add your own. If you decide to use your own self-signed certificate, ensure you have mounted the/config volume in your📄 docker-compose.yml:

services:keeweb:container_name:keewebimage:ghcr.io/keeweb/keeweb:latest# Github imagerestart:unless-stoppedvolumes:            -./keeweb:/config

Then navigate to the newly mounted folder and add your📄 cert.crt and🔑 cert.key files to the📁 /keeweb/keys/* folder.

This image spits out detailed information about its current progress. You can either usedocker logs or a 3rd party app such asPortainer to view the logs.

 Migrations: Started Migrations: 01-nginx-site-confs-default › Skipped Migrations: Complete──────────────────────────────────────────────────────────────────────────────────────────                              Keeweb Password Manager                             ──────────────────────────────────────────────────────────────────────────────────────────  Thanksfor choosing Keeweb. Get started with some of the links below:        Official Repo           https://github.com/keeweb/keeweb        Official Site           https://keeweb.info/        Beta Demo               https://beta.keeweb.info/        Web App                 https://app.keeweb.info/        Favicon Service         https://services.keeweb.info/favicon  If you are making this copy of Keeweb available on a public-facing domain,  please consider using Traefik and Authentik to protect this container from  outside access.        User:Group              1000:1000        (Ports) HTTP/HTTPS      80/443────────────────────────────────────────────────────────────────────────────────────────── SSL: Using existing keys foundin /config/keys Loader: Custom files found, loading them ... Loader: Executing ... Loader: Checking keeweb-plugins Loader: keeweb-plugins already installedin /config/www/plugins; skipping Loader: plugins: Exited 0 Core: Completed loading container

To build your own Keeweb docker image, there are numerous things to remember. Our Keeweb docker image is built from several parts which we host within different branches of our repo.

To build a docker image for Keeweb, you need two different docker images:

• Step 1: Build🔀 docker/alpine-base image
  • When being build, the alpine-base📄 Dockerfile will grab and install the files from this branch🔀 docker/core
• Step 2: Build🔀 docker/keeweb image
• Step 3: Release the docker image built fromStep 2 to Github'sGhcr.io orhub.docker.com

Prior to building the🔀 docker/alpine-base and🔀 docker/keeweb docker images, youmust ensure the following conditions are met. If the below tasks are not performed, your docker container will throw the following errors when started:

• Failed to open apk database: Permission denied
• s6-rc: warning: unable to start service init-adduser: command exited 127
• unable to exec /etc/s6-overlay/s6-rc.d/init-envfile/run: Permission denied
• /etc/s6-overlay/s6-rc.d/init-adduser/run: line 34: kwown: command not found
• /etc/s6-overlay/s6-rc.d/init-adduser/run: /usr/bin/kwown: cannot execute: required file not found

You cannot utilize Windows'Carriage Return Line Feed. All files must be converted to Unix'Line Feed. This can be done withVisual Studio Code. OR; you can run the Linux terminal commanddos2unix to convert these files.

For the branches🔀 docker/alpine-base and🔀 docker/keeweb, you can use the following recursive commands:

# Change ALL filesfind ./ -type f| grep -Ev'.git|*.jpg|*.jpeg|*.png'| xargs dos2unix --# Change run / binariesfind ./ -type f -name'run'| xargs dos2unix --

For the branch🔀 docker/core, you can use the following commands:

dos2unix docker-images.v3dos2unix kwown.v1dos2unix package-install.v1dos2unix with-contenv.v1

The files contained within this repoMUST havechmod 755 /+x executable permissions. If you are using theKeeweb Github Workflow, this is done automatically. If you are builting the images manually; you need to do this. Ensure those files have the correct permissions prior to building the Alpine base docker image.

If you are building the🔀 docker/alpine-base or🔀 docker/keeweb images, you must ensure the files in those branches have the proper permissions. All of the executable files are namedrun:

find ./ -name'run' -exec chmod +x {}\;

If you want to set the permissions manually, run the following:

sudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-adduser/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-crontab-config/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-custom-files/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-envfile/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-folders/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-keygen/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-migrations/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-nginx/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-permissions/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-php/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-samples/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/init-version-checks/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/svc-cron/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/svc-nginx/runsudo chmod +x /root/etc/s6-overlay/s6-rc.d/svc-php-fpm/run

For the branch🔀 docker/core, there are a few files to change. The ending version number may change, but the commands to change the permissions are as follows:

sudo chmod +x docker-images.v3sudo chmod +x kwown.v1sudo chmod +x package-install.v1sudo chmod +x with-contenv.v1

The scripts contained within this🔀 docker/core branch do not need anything done to them. In order to use these scripts, clone theKeeweb Alpine Base branch🔀 docker/alpine-base:

git clone -b docker/alpine-base https://github.com/keeweb/keeweb.git.

Once cloned, the calls to include the scripts in this🔀 docker/core branch are within the📄 Dockerfile and📄 Dockerfile.aarch64. All you need to do is simply build your alpine-base image:

# Build keeweb alpine-base amd64 🖥️docker build --build-arg VERSION=3.20 --build-arg BUILD_DATE=20241216 -t alpine-base:latest -t alpine-base:3.20-amd64 -f Dockerfile.

# Build keeweb alpine-base arm64 🖥️docker build --build-arg VERSION=3.20 --build-arg BUILD_DATE=20241216 -t alpine-base:3.20-arm64 -f Dockerfile.aarch64.

The flow of the process is outlined below:

%%{init: { 'themeVariables': { 'fontSize': '10px' }}}%%flowchart TBsubgraph GRAPH_KEEWEB ["Build keeweb:latest"]    direction TB    obj_step10["`> git clone -b docker/keeweb github.com/keeweb/keeweb.git`"]    obj_step11["`**Dockerfile     Dockerfile.aarch64**`"]    obj_step12["`> docker build \    --build-arg VERSION=1.19.0 \    --build-arg BUILD_DATE=20241216 \    -t keeweb:latest \    -t keeweb:1.19.0-amd64 \    -f Dockerfile . \`"]    obj_step13["`Download **alpine-base** from branch **docker/alpine-base**`"]    obj_step14["`New Image: **keeweb:latest**`"]    style obj_step10 text-align:center,stroke-width:1px,stroke:#555    style obj_step11 text-align:left,stroke-width:1px,stroke:#555    style obj_step12 text-align:left,stroke-width:1px,stroke:#555    style obj_step13 text-align:left,stroke-width:1px,stroke:#555endstyle GRAPH_KEEWEB text-align:center,stroke-width:1px,stroke:transparent,fill:transparentsubgraph GRAPH_ALPINE["Build alpine-base:latest Image"]direction TB    obj_step20["`> git clone -b docker/alpine-base github.com/keeweb/keeweb.git`"]    obj_step21["`**Dockerfile     Dockerfile.aarch64**`"]    obj_step22["`> docker build \    --build-arg VERSION=3.20 \    --build-arg BUILD_DATE=20241216 \    -t docker-alpine-base:latest \    -t docker-alpine-base:3.20-amd64 \    -f Dockerfile . \`"]    obj_step23["`Download files from branch **docker/core**`"]    obj_step24["`New Image: **alpine-base:latest**`"]    style obj_step20 text-align:center,stroke-width:1px,stroke:#555    style obj_step21 text-align:left,stroke-width:1px,stroke:#555    style obj_step22 text-align:left,stroke-width:1px,stroke:#555    style obj_step23 text-align:left,stroke-width:1px,stroke:#555endstyle GRAPH_ALPINE text-align:center,stroke-width:1px,stroke:transparent,fill:transparentGRAPH_KEEWEB --> obj_step10 --> obj_step11 --> obj_step12 --> obj_step13 --> obj_step14GRAPH_ALPINE --> obj_step20 --> obj_step21 --> obj_step22 --> obj_step23 --> obj_step24

Once the base alpine image is built, you can now build the actual docker version of Keeweb. The files for this docker image are stored in the branch🔀 docker/keeweb:

• https://github.com/keeweb/keeweb/tree/docker/keeweb

After the🔀 docker/alpine-base image is built, you can now use that docker image as a base to build the🔀 docker/keeweb image. Navigate to the branch🔀 docker/keeweb and open the files:

• 📄 Dockerfile
• 📄 Dockerfile.aarch64

Next, specify the🔀 docker/alpine-base image which will be used as the foundation of the🔀 docker/keeweb image:

# 📄 DockerfileFROM ghcr.io/keeweb/alpine-base:3.20-amd64# 📄 Dockerfile.aarch64FROM ghcr.io/keeweb/alpine-base:3.20-arm64

After you have completed configuring the🔀 docker/keeweb📄 Dockerfile, you can now build the official version of Keeweb. Remember to build an image for bothamd64 andaarch64.

For the argumentVERSION; specify the current release of Keeweb which will be contained within the docker image. It should be in the format ofYYYYMMDD:

# Build docker/keeweb amd64docker build --build-arg VERSION=1.19.0 --build-arg BUILD_DATE=20241216 -t keeweb:latest -t keeweb:1.19.0 -t keeweb:1.19.0-amd64 -f Dockerfile.

# Build docker/keeweb arm64docker build --build-arg VERSION=1.19.0 --build-arg BUILD_DATE=20241216 -t keeweb:1.19.0-arm64 -f Dockerfile.aarch64.

After you have your🔀 docker/keeweb image built, you can either upload the image to a public repository such as:

• hub.docker.com (Docker Hub)
• ghcr.io (Github)

After it is uploaded, you can use thedocker run command, or create a📄 docker-compose.yml, and call the docker image to be used.

This is discussed in the sectionUsing docker/keeweb Image below.

When building your images with the commands provided above, ensure you create two sets of tags:

the🖥️ amd64 arch gets a few extra tags because it should be the default image people download.

The following are other things to take into consideration when creating the🔀 docker/alpine-base and🔀 docker/keeweb images:

The🔀 docker/alpine-base and🔀 docker/keeweb images support the ability of adding custom scripts that will be ran when the container is started. To create / add a new custom script to the container, you need to create a new folder in the container source files/root folder

mkdir -p /root/custom-cont-init.d/

Within this new folder, add your custom script:

nano /root/custom-cont-init.d/my_customs_script

#!/bin/bashecho"**** INSTALLING BASH ****"apk add --no-cache bash

When you create the docker image, this new script will automatically be loaded. You can also do this via the📄 docker-compose.yml file by mounting a new volume:

services:keeweb:volumes:            -./keeweb:/config            -./custom-scripts:/custom-cont-init.d:ro

The🔀 docker/keeweb image already contains a custom script called📄 /root/custom-cont-init.d/plugins. DoNOT edit this script. It is what automatically downloads the official Keeweb plugins and adds them to the container.

The following workflows are associated to the Keeweb docker image and management of the files:

Prior tov1.19.0, the docker image source files for Keeweb were stored in the🔀 main / master branch within the folder📁 package/docker. Upon release of v1.19.0, the primary storage location of these source files were migrated to their own independent branch🔀 docker/keeweb.

We utilize the Github workflowdeploy-docker-github-sync.yml to copy the source files from the🔀 docker/keeweb branch over to the🔀 main /master branch.

^{deploy-docker-github-sync.yml manual workflow trigger}

Once the workflow is triggered, it will copy the following from the branch🔀 docker/keeweb

• 📁 root
• 📄 Dockerfile
• 📄 Dockerfile.aarch64

This workflow triggers under a few different conditions:

• ☝️ Manual Activation

  When the workflow is activated manually(via the triggerworkflow_dispatch), you can select which branch to copy the docker files to.

  
  

  
  ^{deploy-docker-github-sync.yml destination branch to
  copy docker files to}

  
  

  In the screenshot above, if you select the branch🔀 develop/1.19.0, the docker files from the branch🔀 docker/keeweb will be copied to the branch🔀 develop/1.19.0 within the folder📂 package/docker.

  
  

  Manual activation gives you the ability to adjust a few settings

  Setting	Description
  Use workflow from	Destination branch where the docker files will be copied to
  🔀 Branch › Source	Source branch which contains the docker files
  📂 Folder › Destination	Destination folder where the docker files will be copied to
  🐛 Dry Run (Debug)	Dry run test; does not actually commit changes for files

  
  

• ⬆️ Push

  The workflowdeploy-docker-github-sync.yml will be triggered each time a push is made to the branch🔀 docker/keeweb. The docker files within the branch🔀 docker/keeweb will be copied over to the repositories' default branch which is either🔀 master or🔀 main.

The workflowdeploy-docker-github.yml is responsible for each new release of the Keeweb docker image available to the public.

Upon the workflow being triggered, the branch🔀 docker/keeweb will be accessed, and the files that make up the docker image will be compiled into new public releases for each offered architecture.

• 🖥️amd64:📄 Dockerfile
• 🖥️arm64:📄 Dockerfile.aarch64

Once the new docker images are built, they will be pushed to Github'sghcr.io repository service, and available at:

• https://github.com/orgs/keeweb/packages

^{deploy-docker-github.yml manual triggering}

This workflow triggers under a few different conditions:

• ☝️ Manual Activation

  When the workflow is activated manually(via the triggerworkflow_dispatch), you are given a few settings you can adjust.

  
  

  
  ^{deploy-docker-github.yml manual trigger options}

  
  

  Manual activation gives you the ability to adjust a few settings

  Setting	Description
  Use workflow from	Branch where action is activated. Keep this on🔀 master /main
  📦 Image Name	Name of the image to display onpackages page
  🪪 Image Author	Author of image
  🏷️ Image Version	Version of the docker image to be released
  🪪 ghcr.io Username	Username associated to the Github ghcr.io service
  🐛 Dry Run (Debug)	Simulates a run and outputs debug info, does not actually push an image
  🧪 Development Release	Adds the🔖 -development tag to each docker image If not checked, a release will get the🔖 -latest tag

  
  

• 🔖 Tag Push

  The workflowdeploy-docker-github.yml will be triggered each time a new tag is created. Upon tag creation, the workflow will create a set of new docker images for each offered architecture.

  
  

  The tag assigned to the docker image will be the tag created on the repo'sreleases page.

  
  

  
  ^{Triggering workflow by creating new tag}

  
  

The workflowdeploy-docker-dockerhub.yml is responsible for each new release of the Keeweb docker image available to the public.

Upon the workflow being triggered, the branch🔀 docker/keeweb will be accessed, and the files that make up the docker image will be compiled into new public releases for each offered architecture.

• 🖥️amd64:📄 Dockerfile
• 🖥️arm64:📄 Dockerfile.aarch64

Once the new docker images are built, they will be pushed toDockerhub, and available at:

• https://hub.docker.com/r/antelle/keeweb

^{deploy-docker-dockerhub.yml manual triggering}

This workflow triggers under a few different conditions:

• ☝️ Manual Activation

  When the workflow is activated manually(via the triggerworkflow_dispatch), you are given a few settings you can adjust.

  
  

  
  ^{deploy-docker-dockerhub.yml manual trigger options}

  
  

  Manual activation gives you the ability to adjust a few settings

  Setting	Description
  Use workflow from	Branch where action is activated. Keep this on🔀 master /main
  📦 Image Name	Name of the image to display onpackages page
  🪪 Image Author	Author of image
  🏷️ Image Version	Version of the docker image to be released
  🪪 Dockerhub Username	Username associated to Dockerhub
  🐛 Dry Run (Debug)	Simulates a run and outputs debug info, does not actually push an image
  🧪 Development Release	Adds the🔖 -development tag to each docker image If not checked, a release will get the🔖 -latest tag

  
  

• 🔖 Tag Push

  The workflowdeploy-docker-dockerhub.yml will be triggered each time a new tag is created. Upon tag creation, the workflow will create a set of new docker images for each offered architecture.

  
  

  The tag assigned to the docker image will be the tag created on the repo'sreleases page.

  
  

  
  ^{Triggering workflow by creating new tag}