Converter NOW: a Flutter unit converter you can self-host

The pitch is a converter with no ads and no data collection

The README opens by naming the thing it is replacing. Tired of complicated, cluttered, and ad-filled unit converters, and a few years ago the author realized that most unit converters were not only visually unappealing but also lacked functionality, privacy and ease of use.

The feature list is a set of product decisions rather than a capability list. Fast and Intuitive means real-time conversions as soon as you start typing, with no navigating through menus. Fully Customizable means units can be reorganized by preference. Built-in Calculator means complex calculations happen on any page without switching apps. Daily Currency Exchange Updates means the rates are refreshed each day. Personalize Your Style offers an accent color. Light and Dark Modes switch with the device or manually. Cross-Platform Support covers Android, Web, Linux and Windows.

The last claim is the one that carries the rest. Completely Free means no ads, no data collection and no intrusive permissions, with just internet access for currency updates, and the project states it is 100% open source. The licence is GPL-3.0, and the repository is not archived with the last push on 2026-10-13 and v4.6.3 released on 2026-08-19.

That privacy claim is worth a moment of scrutiny, because it is the kind of statement that is easy to make and hard to check. The README scopes it to no data collection and states the one exception explicitly, internet access for currency updates, so the honest reading is that the app itself does not profile you and does talk to the network for rates. It does not say which service supplies the rates, and the currency update mechanism is not described anywhere in the visible documentation.

Installing the web app is one container command

The alternative installation sources section is where this project becomes interesting for an engineering audience, because the web app is a container image on GitHub Container Registry.

The README says you can self-host the Converter NOW web app on your own machine using either Docker or Podman, and gives one command for each:

docker run -d -p 8080:80 ghcr.io/ferraridamiano/converternow:latest
podman run -d -p 8080:80 ghcr.io/ferraridamiano/converternow:latest

After that the web app is reachable in a browser at `http://localhost:8080`. There is a separate Windows path through winget, and the README also links the Google Play, Microsoft Store, Flathub, F-Droid, GitHub releases, AppImage and a PWA deployment, so the same application is distributed through the channel that fits each platform.

The self-hosting option is the one that distinguishes this from an ordinary converter app. A PWA on a hosted site is convenient until you want to know where the rate data comes from, or you want the converter to keep working on a machine with no route to the internet. Running the container locally puts the whole thing on your own host, and the daily currency updates then go out from your server rather than from someone else's.

There is a hosted instance at converter-now.web.app, which the README links as the PWA and which the repository metadata names as the homepage.

Building from source is a melos monorepo with per-platform outputs

The build section assumes Flutter is already installed along with the tooling for your target platform, such as Android Studio for Android. The extra step is melos, which handles a pre-compiling task, and it is installed with:

dart pub global activate melos

Then you run `melos bootstrap` in the root of the project, which gets all the dependencies, generates the translation files and optimizes the `svg` icons, and you follow the instructions for the platform you want to target. The repository layout supports that monorepo shape, with a `packages/` directory, a `pubspec.yaml`, a `pubspec.lock` and a `melos`-friendly structure, plus a `lib/` directory, `integration_test/`, and a `tools/` directory.

The per-platform build commands are the standard Flutter ones, and the README gives the output location for each. On Android you first disable the signing option in `android/app/build.gradle.kts` and then run `flutter build apk --split-per-abi`, with the output in `build/app/outputs/flutter-apk`. On Linux it is `flutter build linux` and the output is in `build/linux/x64/release/bundle`. On Windows it is `flutter build windows` with the output in `build/windows/runner/Release`. On the web it is `flutter build web` with the output in `build/web`.

There is one deployment caveat for the web build. The README says that if you deploy it not on the base path, you add `--base-href=/path/` to the command and change `/path/` to your path. That is the usual Flutter web deployment wrinkle, and it is worth catching at build time rather than debugging a blank page after deploying.

The Docker image compiles Flutter to wasm and serves it from nginx

The Dockerfile at the repository root is a two-stage build, and the second stage is short enough to be worth reading in full.

The builder stage starts from `debian:13-slim` and installs the usual toolchain plus `libglu1-mesa`. It clones the Flutter SDK at a version supplied by the `flutter_version` build argument, defaulting to stable, and then configures Flutter with desktop, Android and iOS all disabled and only web enabled, before running `flutter doctor` and precaching the web artifacts only.

The interesting part is the application build itself:

RUN flutter pub global activate melos && \
    melos bootstrap && \
    flutter build web --release --wasm --no-web-resources-cdn

Two flags in there matter. `--wasm` compiles the Dart code to WebAssembly rather than to JavaScript, and `--no-web-resources-cdn` stops the build from pulling its web resource bundles from a CDN at runtime, which for a self-hosted image is the difference between a self-contained deployment and one that still phones home.

The final stage is `nginx:alpine-slim`, and it copies the built web output into the nginx html directory. There is a MIME type fix applied with `sed` on nginx's `mime.types`, with a comment that it is a workaround to be removed once a specific nginx pull request is merged, and it adds `mjs` to the `application/javascript` mapping, which is what a wasm build needs. The image exposes port 80 and declares a health check that runs `wget` against localhost every 30 seconds with a 5 second timeout, a 10 second start period and 3 retries.

The local build path is the same shape in miniature. You build the image with `docker buildx build -t converternow .` and then run it with `docker run -d -p 80:80 converternow`, after which it is reachable at `localhost:80`. Note the difference from the published image, which maps host 8080 to container 80, and it is easy to mix the two up.

The Apple platforms are compiled but not tested

The last build section is the shortest and the most candid. For iOS and macOS the README says the app is not tested against those platforms, but that you should be able to compile it for them, and that you first need to generate the platform specific code and then compile it.

That is a meaningful difference from the other four targets. Android, Linux, Windows and web are all covered by the distribution channels in the badges, with a Google Play listing, a Microsoft Store listing, a Flathub listing, an F-Droid listing, GitHub releases with an AppImage, and a hosted PWA. iOS and macOS have none of that.

The Flutter configuration in the Dockerfile makes the reason plain. The builder stage runs `flutter config` with `--no-enable-windows-desktop --no-enable-macos-desktop --no-enable-linux-desktop --no-enable-android --no-enable-ios --enable-web`, so the container image deliberately builds for the web and nothing else, and the precache step mirrors it with `--web --no-ios --no-windows --no-macos --no-linux --no-android`.

The practical advice is to treat Apple support as a build that is likely to succeed and would need your own testing, particularly around the currency rate fetching and the calculator integration, rather than as a supported target. The README does not describe what the untested part is, so the honest position is that the community has not validated those platforms and a maintainer looking to ship an iOS build should plan to do that validation themselves.

The repository also carries tooling for release automation, with a `fastlane/` directory, a `cliff.toml` for changelog generation, a `firebase.json` and a `.firebaserc` for the web deployment, and a `promotional/` directory holding the store badges and screenshots the README embeds.

Editorial conclusion

Adopt Converter NOW if you want a unit converter with no ads, no data collection and a web build you can run on your own machine, and you are comfortable with Flutter and a melos-based monorepo build. Do not adopt it as a library, since it is a finished application rather than a package, and treat the iOS and macOS targets with care because the README says they are not tested. Verify first that the container image serves on the port you expect, since the published image and the locally built one use different port mappings, and confirm the currency rate source still matches your needs before relying on it daily.

Frequently asked questions

Official sources

1. ferraridamiano/ConverterNOW on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases