Updating guides

Dawarich is a rapidly evolving project, and some changes may break compatibility with older versions. This page will serve as a record of the breaking changes and migration paths. Instructions for each version assume that you are updating from the previous version.

After each update, please make sure there is no jobs running in the Sidekiq interface (/sidekiq). If there are, please wait for them to finish. Once all jobs are finished, you can proceed with the update.

1.7.7

warning

This release migrates the Prometheus metrics backend from discourse/prometheus_exporter to Yabeda. If you scrape Dawarich with Prometheus, you must update your scrape configuration, environment variables, and any dashboards or alerts built on the old metric names.

Scrape target

Dawarich now serves metrics in-process — no separate exporter container. Prometheus scrapes a single endpoint on dawarich_app:

scrape_configs:
  - job_name: dawarich
    metrics_path: /metrics
    basic_auth:
      username: prometheus     # value of METRICS_USERNAME
      password: prometheus     # value of METRICS_PASSWORD
    static_configs:
      - targets: ['dawarich_app:3000']

Basic auth is now required. Set METRICS_USERNAME and METRICS_PASSWORD on both dawarich_app and dawarich_sidekiq. Requests without valid credentials return 401.

If Sidekiq is unreachable during a scrape, the web container returns its own metrics only and logs a warning — Prometheus sees a momentary gap in sidekiq_* series rather than a failed scrape.

Environment variables

Remove from docker-compose.yml:

PROMETHEUS_EXPORTER_HOST
PROMETHEUS_EXPORTER_HOST_SIDEKIQ

Both are obsolete. Metrics are no longer hosted by a separate process, so there is nothing to bind to.

Keep / add:

Variable	Notes
`PROMETHEUS_EXPORTER_ENABLED`	Still the single on/off switch. Must be `true` on both services.
`METRICS_USERNAME`, `METRICS_PASSWORD`	Unchanged from previous releases. Required.
`PROMETHEUS_EXPORTER_PORT`	Now the port the in-process Sidekiq metrics endpoint binds to on `dawarich_sidekiq` (default `9394`).
`SIDEKIQ_METRICS_URL` (new, optional)	Internal URL the web container uses to fetch Sidekiq metrics. Default `http://dawarich_sidekiq:9394/metrics`. Override on Dokku, Kubernetes, or any deployment where the worker hostname differs from the docker-compose default.

Metric name renames

dawarich_archive_* metric names are unchanged — dashboards built on them continue to work.

Infrastructure metric names have changed. Update any dashboard or alert that references the old names:

Category	Before (`prometheus_exporter`)	After (Yabeda)
HTTP requests total	`ruby_http_requests_total`	`rails_requests_total`
HTTP request duration	`ruby_http_request_duration_seconds`	`rails_request_duration`
Sidekiq jobs total	`ruby_sidekiq_jobs_total`	`sidekiq_jobs_executed_total`
Sidekiq failed jobs	`ruby_sidekiq_failed_jobs_total`	`sidekiq_jobs_failed_total`
Sidekiq job duration	`ruby_sidekiq_job_duration_seconds`	`sidekiq_job_runtime_seconds`
Sidekiq queue latency	`ruby_sidekiq_queue_latency_seconds`	`sidekiq_queue_latency`
Sidekiq queue backlog	`ruby_sidekiq_queue_backlog_total`	`sidekiq_jobs_waiting_count`
Sidekiq process count	`ruby_sidekiq_process_count`	`sidekiq_active_processes`
Puma workers	`ruby_puma_workers`	`puma_workers`
Puma backlog	`ruby_puma_request_backlog`	`puma_backlog`
Puma thread-pool capacity	`ruby_puma_thread_pool_capacity`	`puma_pool_capacity`
ActiveRecord pool size	`active_record_connection_pool_connections`	`activerecord_connection_pool_size`
Process / GC (`ruby_rss`, `ruby_heap_live_slots`, …)	emitted by default	not emitted by default; register a custom Yabeda group if needed

For the full updated reference, see Monitoring with Prometheus.

0.28.0

warning

If you're updating from a version before 0.28.0, first read sections about most recent breaking changes. What was introduced in 0.27.0 was later reverted with some changes in 0.28.0. Please pay attention and read release notes before updating.

⚠️ This release includes a breaking change. ⚠️

Well, we're moving back to Sidekiq and Redis for background jobs and caching. Unfortunately, SolidQueue and SolidCache brought more problems than they solved. Please update your docker-compose.yml to use Redis and Sidekiq.

Before updating, you can remove dawarich_development_queue database from your postgres. All *.sqlite3 files in dawarich_sqlite_data volume can be removed as well.

networks:
  dawarich:
services:
+ dawarich_redis:
+   image: redis:7.4-alpine
+   container_name: dawarich_redis
+   command: redis-server
+   networks:
+     - dawarich
+   volumes:
+     - dawarich_shared:/data
+   restart: always
+   healthcheck:
+     test: [ "CMD", "redis-cli", "--raw", "incr", "ping" ]
+     interval: 10s
+     retries: 5
+     start_period: 30s
+     timeout: 10s
...
  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    volumes:
      - dawarich_public:/var/app/public
      - dawarich_watched:/var/app/tmp/imports/watched
      - dawarich_storage:/var/app/storage
      - dawarich_db_data:/dawarich_db_data
-     - dawarich_sqlite_data:/dawarich_sqlite_data
    ...
    restart: on-failure
    environment:
      RAILS_ENV: development
+     REDIS_URL: redis://dawarich_redis:6379
      DATABASE_HOST: dawarich_db
      DATABASE_USERNAME: postgres
      DATABASE_PASSWORD: password
      DATABASE_NAME: dawarich_development
-     # PostgreSQL database name for solid_queue
-     QUEUE_DATABASE_NAME: dawarich_development_queue
-     QUEUE_DATABASE_PASSWORD: password
-     QUEUE_DATABASE_USERNAME: postgres
-     QUEUE_DATABASE_HOST: dawarich_db
-     QUEUE_DATABASE_PORT: 5432
-     # SQLite database paths for cache and cable databases
-     CACHE_DATABASE_PATH: /dawarich_sqlite_data/dawarich_development_cache.sqlite3
-     CABLE_DATABASE_PATH: /dawarich_sqlite_data/dawarich_development_cable.sqlite3
...
    depends_on:
      dawarich_db:
        condition: service_healthy
        restart: true
+     dawarich_redis:
+       condition: service_healthy
+       restart: true
...
+ dawarich_sidekiq:
+   image: freikin/dawarich:latest
+   container_name: dawarich_sidekiq
+   volumes:
+     - dawarich_public:/var/app/public
+     - dawarich_watched:/var/app/tmp/imports/watched
+     - dawarich_storage:/var/app/storage
+   networks:
+     - dawarich
+   stdin_open: true
+   tty: true
+   entrypoint: sidekiq-entrypoint.sh
+   command: ['sidekiq']
+   restart: on-failure
+   environment:
+     RAILS_ENV: development
+     REDIS_URL: redis://dawarich_redis:6379
+     DATABASE_HOST: dawarich_db
+     DATABASE_USERNAME: postgres
+     DATABASE_PASSWORD: password
+     DATABASE_NAME: dawarich_development
+     APPLICATION_HOSTS: localhost
+     BACKGROUND_PROCESSING_CONCURRENCY: 10
+     APPLICATION_PROTOCOL: http
+     PROMETHEUS_EXPORTER_ENABLED: false
+     PROMETHEUS_EXPORTER_HOST: dawarich_app
+     PROMETHEUS_EXPORTER_PORT: 9394
+     SELF_HOSTED: "true"
+     STORE_GEODATA: "true"
+   logging:
+     driver: "json-file"
+     options:
+       max-size: "100m"
+       max-file: "5"
+   healthcheck:
+     test: [ "CMD-SHELL", "pgrep -f sidekiq" ]
+     interval: 10s
+     retries: 30
+     start_period: 30s
+     timeout: 10s
+   depends_on:
+     dawarich_db:
+       condition: service_healthy
+       restart: true
+     dawarich_redis:
+       condition: service_healthy
+       restart: true
+     dawarich_app:
+       condition: service_healthy
+       restart: true
...
volumes:
  dawarich_db_data:
- dawarich_sqlite_data:
  dawarich_shared:
  dawarich_public:
  dawarich_watched:
  dawarich_storage:

0.27.4 - 2025-06-06

Update your docker-compose.yml to use SQLite database names for queue, cache and cable databases.

...
  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    volumes:
      - dawarich_public:/var/app/public
      - dawarich_watched:/var/app/tmp/imports/watched
      - dawarich_storage:/var/app/storage
      - dawarich_db_data:/dawarich_db_data
+     - dawarich_sqlite_data:/dawarich_sqlite_data
    ...
    restart: on-failure
    environment:
    ...
      DATABASE_NAME: dawarich_development
+     # PostgreSQL database name for solid_queue
+     QUEUE_DATABASE_NAME: dawarich_development_queue
+     QUEUE_DATABASE_PASSWORD: password
+     QUEUE_DATABASE_USERNAME: postgres
+     QUEUE_DATABASE_PORT: 5432
+     QUEUE_DATABASE_HOST: dawarich_db
      # SQLite database paths for cache and cable databases
-     QUEUE_DATABASE_PATH: /dawarich_db_data/dawarich_development_queue.sqlite3
-     CACHE_DATABASE_PATH: /dawarich_db_data/dawarich_development_cache.sqlite3
-     CABLE_DATABASE_PATH: /dawarich_db_data/dawarich_development_cable.sqlite3
+     CACHE_DATABASE_PATH: /dawarich_sqlite_data/dawarich_development_cache.sqlite3
+     CABLE_DATABASE_PATH: /dawarich_sqlite_data/dawarich_development_cable.sqlite3

volumes:
  dawarich_db_data:
+ dawarich_sqlite_data:
  dawarich_shared:
  dawarich_public:
  dawarich_watched:
  dawarich_storage:
...

0.27.0

warning

If you're updating from a version before 0.27.0, first read sections about most recent breaking changes. What was introduced in 0.27.0 was later reverted with some changes in 0.28.0. Please pay attention and read release notes before updating.

Starting 0.27.0, Dawarich is using SolidQueue and SolidCache to run background jobs and cache data. Before updating, make sure your Sidekiq queues (https://your_dawarich_app/sidekiq) are empty.

Moving to SolidQueue and SolidCache will require creating new SQLite databases, which will be created automatically when you start the app. They will be stored in the dawarich_db_data volume.

Background jobs interface is now available at /jobs page.

Please, update your docker-compose.yml and add the following:

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    volumes:
      - dawarich_public:/var/app/public
      - dawarich_watched:/var/app/tmp/imports/watched
      - dawarich_storage:/var/app/storage
+     - dawarich_db_data:/dawarich_db_data
...
    environment:
      ...
      DATABASE_NAME: dawarich_development
      # SQLite database paths for secondary databases
+     QUEUE_DATABASE_PATH: /dawarich_db_data/dawarich_development_queue.sqlite3
+     CACHE_DATABASE_PATH: /dawarich_db_data/dawarich_development_cache.sqlite3
+     CABLE_DATABASE_PATH: /dawarich_db_data/dawarich_development_cable.sqlite3

0.26.0

Starting this version, Dawarich requires PostgreSQL 17 with PostGIS 3.5. If you haven't updated your database image yet, please consider doing so as suggested in the docs on the website. Simply replacing the image in the docker-compose.yml unfortunately doesn't work, as PostgreSQL 17 is not backwards compatible with 14 (which was used in previous versions).

If you have encountered problems with moving to a PostGIS image while still on Postgres 14, I collected a selection of compatible docker images for different CPU architectures, which you can also find in the docs. New users will be automatically provisioned with PostgreSQL 17 with PostGIS 3.5 with default docker-compose.yml file.

You still may use PostgreSQL 14, but no support will be provided for it starting this version. It's strongly recommended to update to PostgreSQL 17.

Changed

Dawarich now uses PostgreSQL 17 with PostGIS 3.5 by default.

0.25.4

⚠️ This release includes a breaking change. ⚠️

Make sure to add dawarich_storage volume and SELF_HOSTED: "true" to your docker-compose.yml file. Example:

...

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    volumes:
      - dawarich_public:/var/app/public
      - dawarich_watched:/var/app/tmp/imports/watched
+     - dawarich_storage:/var/app/storage
...
    environment:
+     SELF_HOSTED: "true"

...

  dawarich_sidekiq:
    image: freikin/dawarich:latest
    container_name: dawarich_sidekiq
    volumes:
      - dawarich_public:/var/app/public
      - dawarich_watched:/var/app/tmp/imports/watched
+     - dawarich_storage:/var/app/storage
...
    environment:
+     SELF_HOSTED: "true"


volumes:
  dawarich_db_data:
  dawarich_shared:
  dawarich_public:
  dawarich_watched:
+ dawarich_storage:

In this release we're changing the way import files are being stored. Previously, they were being stored in the raw_data column of the imports table. Now, they are being attached to the import record. All new imports will be using the new storage, to migrate existing imports, you can use the bundle exec rake imports:migrate_to_new_storage task. Run it in the container shell.

This is an optional task, that will not affect your points or other data. Big imports might take a while to migrate, so be patient.

Also, you can now migrate existing exports to the new storage using the bundle exec rake exports:migrate_to_new_storage task (in the container shell) or just delete them.

If your hardware doesn't have enough memory to migrate the imports, you can delete your imports and re-import them.

0.25.0

Visits and places

The release page: https://github.com/Freika/dawarich/releases/tag/0.25.0

There is a known issue when data migrations are not being run automatically on some systems. If you're experiencing issues when opening map page, trips page or when trying to see visits, try executing the following command in the Console:

Errors on the map page

If on the map page you see errors like this:

undefined method `y' for nil:NilClass

This means that the data migration job that supposed to move coordinates from longitude and latitude columns to lonlat column on points table was not run. We can fix this by running the following command in the Console:

User.includes(:tracked_points).find_each do |user|
  user.tracked_points.where(lonlat: nil).update_all('lonlat = ST_SetSRID(ST_MakePoint(longitude, latitude), 4326)')
end

This will update the lonlat column for all the points. After this, the map should work again.

If this script failed with a killed message, you have ran out of memory. Simply repeat the command again, it will pick up from the last processed point.

If you experiencing something similar to the following error:

Caused by PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "index_points_on_lonlat_timestamp_user_id"
DETAIL:  Key (lonlat, "timestamp", user_id)=(0101000020E6100000E2E5E95C51522140B6D8EDB3CA184940, 1737716451, 2) already exists.

This means, you have some points with the same coordinates, timestamp and user_id. This usually should not happen, but we can remove the duplicates. Run the following command in the Console:

user_id = 2 # (your user id based on error message above)
timestamp = 1739235618 # (your problematic timestamp, based on error message above)
points = Point.where(user_id: user_id, timestamp: timestamp)

points.size # This will return number of duplicated points

points.drop(1).each(&:destroy) # This will remove all but the first point.

After this, run the script from the previous step again. Repeat, if you see the same for different timestamp or user_id.

The "your user is not active" errors / 401 errors

In the Console, run the following command:

User.find_by(email: "[email protected]").update(status: :active)

This will activate your account.

0.23.6

In this release, Dawarich switched to using PostGIS as the database image.

postgis/postgis:14-3.5

In your docker-compose.yml change image for postgres:

dawarich_db:
-   image: postgres:14.2-alpine
+   image: postgis/postgis:14-3.5-alpine
    shm_size: 1G
    container_name: dawarich_db

If you're on an ARM system and already updated your postgres to 17, use ghcr.io/baosystems/postgis:17-3.5 image instead of postgis/postgis:14-3.5-alpine. Depending on which postgres version you're using, you can select a fitting docker image to replace your old one here: https://github.com/ImreSamu/docker-postgis?tab=readme-ov-file#recommended-versions-for-new-users

Also, have a look at the moving to postgis guide.

0.22.1

Gems caching volume from the docker-compose.yml file. #638

To update existing docker-compose.yml to new changes, refer to the following:

  dawarich_app:
    image: freikin/dawarich:latest
...
    volumes:
-      - dawarich_gem_cache_app:/usr/local/bundle/gems
...
  dawarich_sidekiq:
    image: freikin/dawarich:latest
...
    volumes:
-      - dawarich_gem_cache_app:/usr/local/bundle/gems
...

volumes:
  dawarich_db_data:
- dawarich_gem_cache_app:
- dawarich_gem_cache_sidekiq:
  dawarich_shared:
  dawarich_public:
  dawarich_watched:

0.22.0

Docker-related files were moved to the docker directory and some of them were renamed. Before upgrading, study carefully changes in the docker/docker-compose.yml file and update your docker-compose file accordingly, so it uses the new files and commands. Copying docker/docker-compose.yml blindly may lead to errors.

No volumes were removed or renamed, so with a proper docker-compose file, you should be able to upgrade without any issues.

To update existing docker-compose.yml to new changes, refer to the following:

  dawarich_app:
    image: freikin/dawarich:latest
...
-    entrypoint: dev-entrypoint.sh
-    command: ['bin/dev']
+    entrypoint: web-entrypoint.sh
+    command: ['bin/rails', 'server', '-p', '3000', '-b', '::']
...
  dawarich_sidekiq:
    image: freikin/dawarich:latest
...
-    entrypoint: dev-entrypoint.sh
-    command: ['bin/dev']
+    entrypoint: sidekiq-entrypoint.sh
+    command: ['bundle', 'exec', 'sidekiq']

0.21.0

The dawarich_db service now can use a custom postgresql.conf file.

As @tabacha pointed out in #549, the default shm_size for the dawarich_db service is too small and it may lead to database performance issues. This release introduces a shm_size parameter to the dawarich_db service to increase the size of the shared memory for PostgreSQL. This should help database with peforming vacuum and other operations. Also, it introduces a custom postgresql.conf file to the dawarich_db service.

To mount a custom postgresql.conf file, you need to create a postgresql.conf file in the dawarich_db service directory and add the following line to it:

  dawarich_db:
    image: postgres:14.2-alpine
    shm_size: 1G
    container_name: dawarich_db
    volumes:
      - dawarich_db_data:/var/lib/postgresql/data
      - dawarich_shared:/var/shared
+     - ./postgresql.conf:/etc/postgresql/postgresql.conf # Provide path to custom config
  ...
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U postgres -d dawarich_development" ]
      interval: 10s
      retries: 5
      start_period: 30s
      timeout: 10s
+   command: postgres -c config_file=/etc/postgresql/postgresql.conf # Use custom config

To ensure your database is using custom config, you can connect to the container (docker exec -it dawarich_db psql -U postgres) and run SHOW config_file; command. It should return the following path: /etc/postgresql/postgresql.conf.

An example of a custom postgresql.conf file is provided in the postgresql.conf.example file.

0.19.6

The dawarich_shared volume now being mounted to /data instead of /var/shared within the container. It fixes Redis data being lost on container restart.

To change this, you need to update the docker-compose.yml file:

  dawarich_redis:
    image: redis:7.0-alpine
    container_name: dawarich_redis
    command: redis-server
    volumes:
+     - dawarich_shared:/data
    restart: always
    healthcheck:

0.19.4

The GET /api/v1/trips/:id/photos endpoint now returns a different structure of the response:

{
  id: 1,
  latitude: 10,
  longitude: 10,
  localDateTime: "2024-01-01T00:00:00Z",
  originalFileName: "photo.jpg",
  city: "Berlin",
  state: "Berlin",
  country: "Germany",
  type: "image",
+ orientation: "portrait",
  source: "photoprism"
}

0.19.0

The GET /api/v1/photos endpoint now returns following structure of the response:

[
  {
    "id": "1",
    "latitude": 11.22,
    "longitude": 12.33,
    "localDateTime": "2024-01-01T00:00:00Z",
    "originalFileName": "photo.jpg",
    "city": "Berlin",
    "state": "Berlin",
    "country": "Germany",
    "type": "image", // "image" or "video"
    "source": "photoprism" // "photoprism" or "immich"
  }
]

Volumes in docker-compose.yml were renamed:

volumes:
-  db_data:
-  gem_cache:
-  shared_data:
-  public:
-  watched:
+  dawarich_db_data:
+  dawarich_gem_cache_app:
+  dawarich_gem_cache_sidekiq:
+  dawarich_shared:
+  dawarich_public:
+  dawarich_watched:

For existing instances, there is no need renaming them.

0.16.7

Prometheus exporter is now bound to 0.0.0.0 instead of localhost. PROMETHEUS_EXPORTER_HOST and PROMETHEUS_EXPORTER_PORT env vars were added to the docker-compose.yml file to allow you to set the host and port for the Prometheus exporter. They should be added to both dawarich_app and dawarich_sidekiq services.

Example:

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    environment:
      ...
      PROMETHEUS_EXPORTER_ENABLED: "true"
+     PROMETHEUS_EXPORTER_HOST: 0.0.0.0
+     PROMETHEUS_EXPORTER_PORT: "9394"

  dawarich_sidekiq:
    image: freikin/dawarich:latest
    container_name: dawarich_sidekiq
    environment:
      ...
      PROMETHEUS_EXPORTER_ENABLED: "true"
+     PROMETHEUS_EXPORTER_HOST: dawarich_app
+     PROMETHEUS_EXPORTER_PORT: "9394"

0.16.6

Dawarich now can export metrics to Prometheus. You can find the metrics at your.host:9394/metrics endpoint. The metrics are being exported in the Prometheus format and can be scraped by Prometheus server. To enable exporting, set the PROMETHEUS_EXPORTER_ENABLED env var in your docker-compose.yml to true.

Example:

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    environment:
      ...
+     PROMETHEUS_EXPORTER_ENABLED: "true"

0.15.11

⚠️ The instruction to import Records.json from Google Takeout now mentions tmp/imports directory instead of public/imports. ⚠️ #326
Hostname definition for Sidekiq healtcheck to solve #344. See the diff:

  dawarich_sidekiq:
    image: freikin/dawarich:latest
    container_name: dawarich_sidekiq
    healthcheck:
-     test: [ "CMD-SHELL", "bundle exec sidekiqmon processes | grep $(hostname)" ]
+     test: [ "CMD-SHELL", "bundle exec sidekiqmon processes | grep ${HOSTNAME}" ]

Renamed directories used by app and sidekiq containers for gems cache to fix #339:

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_sidekiq
    volumes:
-     - gem_cache:/usr/local/bundle/gems
+     - gem_cache:/usr/local/bundle/gems_app

...

  dawarich_sidekiq:
    image: freikin/dawarich:latest
    container_name: dawarich_sidekiq
    volumes:
-     - gem_cache:/usr/local/bundle/gems
+     - gem_cache:/usr/local/bundle/gems_sidekiq

0.15.3

To expose the watcher functionality to the user, a new directory /tmp/imports/watched/ was created. Add new volume to the docker-compose.yml file to expose this directory to the host machine.

  ...

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    volumes:
      - gem_cache:/usr/local/bundle/gems
      - public:/var/app/public
+     - watched:/var/app/tmp/imports/watched

  ...

  dawarich_sidekiq:
      image: freikin/dawarich:latest
      container_name: dawarich_sidekiq
      volumes:
        - gem_cache:/usr/local/bundle/gems
        - public:/var/app/public
+       - watched:/var/app/tmp/imports/watched

    ...

volumes:
  db_data:
  gem_cache:
  shared_data:
  public:
+ watched:

0.13.3

Support for miles. To switch to miles, provide DISTANCE_UNIT environment variable with value mi in the docker-compose.yml file. Default value is km.

It's recommended to update your stats manually after changing the DISTANCE_UNIT environment variable. You can do this by clicking the "Update stats" button on the Stats page.

⚠️IMPORTANT⚠️: All settings are still should be provided in meters. All calculations though will be converted to feets and miles if DISTANCE_UNIT is set to mi.

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    environment:
      APPLICATION_HOST: "localhost"
      APPLICATION_PROTOCOL: "http"
      APPLICATION_PORT: "3000"
      TIME_ZONE: "UTC"
+     DISTANCE_UNIT: "mi"
  dawarich_sidekiq:
    image: freikin/dawarich:latest
    container_name: dawarich_sidekiq
    environment:
      APPLICATION_HOST: "localhost"
      APPLICATION_PROTOCOL: "http"
      APPLICATION_PORT: "3000"
      TIME_ZONE: "UTC"
+     DISTANCE_UNIT: "mi"

0.13.0

Default exporting format is now GeoJSON instead of Owntracks-like JSON. This will allow you to use the exported data in other applications that support GeoJSON format. It's also important to highlight, that GeoJSON format does not describe a way to store any time-related data. Dawarich relies on the timestamp field in the GeoJSON format to determine the time of the point. The value of the timestamp field should be a Unix timestamp in seconds. If you import GeoJSON data that does not have a timestamp field, the point will not be imported.

Example of a valid point in GeoJSON format:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [13.350110811262352, 52.51450815]
  },
  "properties": {
    "timestamp": 1725310036
  }
}

0.12.3

Resource limits to docke-compose.yml file to prevent server overload. Feel free to adjust the limits to your needs.

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    ...
    depends_on:
      - dawarich_db
      - dawarich_redis
+   deploy:
+     resources:
+       limits:
+         cpus: '0.50'    # Limit CPU usage to 50% of one core
+         memory: '2G'    # Limit memory usage to 2GB

  dawarich_sidekiq:
    image: freikin/dawarich:latest
    container_name: dawarich_sidekiq
    ...
    depends_on:
      - dawarich_db
      - dawarich_redis
      - dawarich_app
+   deploy:
+     resources:
+       limits:
+         cpus: '0.50'    # Limit CPU usage to 50% of one core
+         memory: '2G'    # Limit memory usage to 2GB

0.10.0

Redis and DB containers are now being automatically restarted if they fail. Update your docker-compose.yml if necessary

  services:
  dawarich_redis:
    image: redis:7.0-alpine
    command: redis-server
    networks:
      - dawarich
    volumes:
      - shared_data:/var/shared/redis
+   restart: always
  dawarich_db:
    image: postgres:14.2-alpine
    container_name: dawarich_db
    volumes:
      - db_data:/var/lib/postgresql/data
      - shared_data:/var/shared
    networks:
      - dawarich
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
+   restart: always

0.8.7

Added a logging config to the docker-compose.yml file to prevent logs from overflowing the disk. Now logs are being rotated and stored in the log folder in the root of the application. You can find usage example in the the repository's docker-compose.yml file. Make sure to add this config to both dawarich_app and dawarich_sidekiq services.

  logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "5"

0.7.0

The /api/v1/points endpoint is removed. Please use /api/v1/owntracks/points endpoint to upload your points from OwnTracks mobile app instead.

0.6.1

Please update your docker-compose.yml file to include the following changes:

  dawarich_sidekiq:
    image: freikin/dawarich:latest
    container_name: dawarich_sidekiq
    volumes:
      - gem_cache:/usr/local/bundle/gems
+     - public:/var/app/public

0.6.0

Volume, exposed to the host machine for placing files to import was changed. See the changes below.

Path for placing files to import was changed from tmp/imports to public/imports.

  ...

  dawarich_app:
    image: freikin/dawarich:latest
    container_name: dawarich_app
    volumes:
      - gem_cache:/usr/local/bundle/gems
-     - tmp:/var/app/tmp
+     - public:/var/app/public/imports

  ...

  ...

volumes:
  db_data:
  gem_cache:
  shared_data:
- tmp:
+ public:

0.4.0

/api/v1/points is still working, but will be deprecated in nearest future. Please use /api/v1/owntracks/points instead.
All existing points recorded directly to the database via Owntracks or Overland will be attached to the user with id 1.

0.3.2

In order to import Records.json from Google Takeout, you need to update your docker-compose.yml: https://github.com/Freika/dawarich/commit/b4116cfd72e643f5421b6f1bb33d49758f6e7e0f#diff-e45e45baeda1c1e73482975a664062aa56f20c03dd9d64a827aba57775bed0d3

0.2.0

This release changes how Dawarich handles a city visit threshold. Previously, the MINIMUM_POINTS_IN_CITY environment variable was used to determine the minimum number of points in a city to consider it as visited. Now, the MIN_MINUTES_SPENT_IN_CITY environment variable is used to determine the minimum minutes between two points to consider them as visited the same city.

The logic behind this is the following: if you have a lot of points in a city, it doesn't mean you've spent a lot of time there, especially if your OwnTracks app was in "Move" mode. So, it's better to consider the time spent in a city rather than the number of points.

In your docker-compose.yml file, you need to replace the MINIMUM_POINTS_IN_CITY environment variable with MIN_MINUTES_SPENT_IN_CITY. The default value is 60, in minutes.

1.7.7​

Scrape target​

Environment variables​

Metric name renames​

0.28.0​

0.27.4 - 2025-06-06

0.27.0​

0.26.0​

0.25.4​

0.25.0​

0.23.6​

0.22.1​

0.22.0​

0.21.0​

0.19.6​

0.19.4​

0.19.0​

0.16.7​

0.16.6​

0.15.11​

0.15.3​

0.13.3​

0.13.0​

0.12.3​

0.10.0​

0.8.7​

0.7.0​

0.6.1​

0.6.0​

0.4.0​

0.3.2​

0.2.0​

1.7.7

Scrape target

Environment variables

Metric name renames

0.28.0

0.27.0

0.26.0

0.25.4

0.25.0

0.23.6

0.22.1

0.22.0

0.21.0

0.19.6

0.19.4

0.19.0

0.16.7

0.16.6

0.15.11

0.15.3

0.13.3

0.13.0

0.12.3

0.10.0

0.8.7

0.7.0

0.6.1

0.6.0

0.4.0

0.3.2

0.2.0