Docker image for Etebase Server, also known as EteSync 2.0, based on the server repository by Tom Hacohen.
The following tags are built on latest Python image and latest version of Etebase Server
latest
(tags/latest/Dockerfile)slim
(tags/slim/Dockerfile)alpine
(tags/alpine/Dockerfile) Release builds are available as versioned tags, for example: X.Y.Z
or X.Y.Z-type
docker run -d -e SUPER_USER=admin -p 80:3735 -v /path/on/host:/data victorrds/etesync
Create a container running Etebase using http protocol.
You can find more examples, using docker-compose
here
All Etebase image variants share the same folder structure:
Contains the Etebase Server source code, please avoid any changes or mounting this folder.
By default this is the volume where all user data and server configuration are located
/data/etebase-server.ini
: Server configuration file, location can be changed using ETEBASE_EASY_CONFIG_PATH
environment ;/data/media
: The directory where user data is stored, although this location can be changed¹, it's not recommended;/data/secret.txt
: File that contains the value for Django's SECRET_KEY, this location can be changed¹/data/db.sqlite3
: Database file, if SQLite is chosen, this location can be changed¹¹ All the locations are set in the etebase-server.ini
file, or on the first run startup using environment variables.
Here you will find the static files needed to be shared with a reverse proxy, like nginx, when using uwsgi
or asgi
protocols, the /entrypoint.sh
checks this files to update or recreate if not found.
By default, the container runs with the user and group etebase, both using 373 as the numeric ID. If mounting any directory above to the host, instead of using Docker volumes, there are two options
The directories must have the correct permission, e.g.:
$ chown -vR 373:373 /host/data/path
changed ownership of '/host/data/path' from user:group to 373:373
$ docker run -v /host/data/path:/data victorrds/etebase
Change the user running the container:
$ stat -c '%u:%g' /host/data/path
1000:1000
$ docker run -u 1000:1000 -v /host/data/path:/data victorrds/etebase
The available Etebase settings are set in the /data/etebase-server.ini
file. If not found, the /entrypoint.sh
will generate it based on the Environment Variables explained below.
uvicorn
: starts using uvicorn, an ASGI server implementation with HTTP/1.1 and WebSockets support. Runs without SSL and must be used with a reverse-proxy/web server, such as nginx, traefik, and others. Aliases: http
, http-socket
asgi
;uvicorn-https
: same as above but with SSL/TLS support enabled. Certificates must be mounted in the container. Alias: https
;uwsgi
, daphne
and Django-server
, but these are no longer supported. See #103;/entrypoint.sh
. Does not change the output of the etebase server;/entrypoint.sh
with set -x
for debug purposes;false
, more details below;/data/etebase-server.ini
;/data/media
;sqlite
(default) and postgres
;ALLOWED_HOSTS
setting must be a comma-separated list of valid domains and/or IP addresses. The server uses this list to set Django's CSRF_TRUSTED_ORIGINS setting. This list must contain the domain name used to access the server. For more details, see etesync/server#183. Default: localhost,127.0.0.1,[::1]
;/data/secret.txt
;false
;en-us
;UTC
. Must be a valid tz database name
. Valid names can be found at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones;false
;² For more details, please refer to the Etebase Server README.md
If DB_ENGINE is set to sqlite
:
/data/db.sqlite3
If DB_ENGINE is set to postgres
the following variables can be used (only default values are listed):
etebase
;DATABASE_NAME
if not set;DATABASE_USER
if not set;database
5432
For LDAP integration, use the following variables. This is advanced usage; please refer to the etesync/server@fac36aa commit for details:
cache_ttl
to the preferred amount of hours a cache entry should be viewed as valid (optional);As an alternative to passing sensitive information via environment variables, _FILE may be appended to some of the previously listed environment variables, causing the initialization script to load the values for those variables from files present in the container. In particular, this can be used to load passwords from Docker secrets stored in /run/secrets/
docker run -d --name etebase \
-e DB_ENGINE=postgres \
-e POSTGRES_PASSWORD_FILE=/run/secrets/postgres-passwd \
victorrds/etebase
Currently, this is only supported for DB_ENGINE, DATABASE_NAME, DATABASE_USER, DATABASE_PASSWORD, SUPER_USER, and SUPER_PASS.
This image exposes the 3735/TCP port.
For questions, please use Discussions. Any bugs, please report to the repository Issue Tracker.
To build the images, choose a Dockerfile and run:
docker build -f tags/alpine/Dockerfile -t etebase:alpine .
This will create an image using the Etebase master branch. To build using a release version, set the ETE_VERSION
build argument:
docker build --build-arg ETE_VERSION=v0.5.3 -f tags/base/Dockerfile -t etebase:dev .
Setting the SUPER_
variables on the first run will trigger the creation of a superuser after the database is ready.
At any moment after the database is ready, you can create a new superuser by running and following the prompts:
docker exec -it {container_name} python manage.py createsuperuser
If AUTO_UPDATE
is not set, you can update by running:
docker exec -it {container_name} python manage.py migrate
To run Etebase Server with uvicorn using HTTPS, you need to mount valid certificates.
By default, Etebase will look for the files /certs/crt.pem
and /certs/key.pem
. If you change this location, update the X509_CRT and X509_KEY environment variables accordingly.
The Etebase server upgraded its Django version to 4.2+, and now a valid value for the CSRF_TRUSTED_ORIGINS setting must be provided. To resolve this issue, add the domain names and/or IP addresses of the server to the [allowed_hosts]
section of the etebase-server.ini
file.
If you are setting up a new installation and do not have an ini file yet, use the ALLOWED_HOSTS
environment variable to generate the correct ini file.
Example:
[allowed_hosts]
allowed_host1 = example.com
allowed_host2 = api.example.com
allowed_host3 = 10.0.0.1
; wildcard are also valid, but * alone will not work
allowed_host4 = *.etebase.example.com
For more details see this PR: etesync/server#183.
As of version 0.14.0, I have deprecated the support for arm/v7
Docker images for the Etebase Server. This means that new versions and updates will no longer be provided for the arm/v7
architecture.
Many dependencies required by the Etebase Server have become increasingly difficult or impossible to build on the arm/v7
architecture using the default base Python images.
Etesync 1.0 and Etebase (Etesync 2.0), database and server, are incompatible. Given the end-to-end encryption nature and structural changes of this software, it is impossible to migrate the data without knowing the users' keys.
To move the data, you must create a new instance with a new database. While running both servers simultaneously, use the web client tool or mobile applications to migrate your data. After all users have migrated, the legacy server can be shut down.
The new images have breaking changes. To avoid any damage, the entrypoint.sh
will check if the database is compatible before making any changes.
Etesync 1.0 images are available through the legacy
tags. Base images are outdated and no more work will be done.
legacy
(legacy:tags/latest/Dockerfile)legacy-slim
(legacy:tags/slim/Dockerfile)legacy-alpine
(legacy:tags/alpine/Dockerfile)