To self-host Central, you must have a fully-qualified domain name (e.g., central.example.com) mapped to your server. If you are using an IP or localhost, you'll have these kinds of problems. What do you have as your DOMAIN and SSL_TYPE in your .env file?
@yanokwa, Thanks for your help. However, I still face the same problem and here are steps I tried
1. Update .env file
# Use fully qualified domain names. Set to DOMAIN=local if SSL_TYPE=selfsign.
DOMAIN=myodk.local.net
# Used for Let's Encrypt expiration emails and Enketo technical support emails
SYSADMIN_EMAIL=a_user@mycompany.com
# Options: letsencrypt, customssl, upstream, selfsign
SSL_TYPE=selfsign
# Do not change if using SSL_TYPE=letsencrypt
HTTP_PORT=8099
HTTPS_PORT=4433
Hello @jdang, this issue usually happens when Enketo (the form preview tool) can't connect to the ODK Central backend, often due to network or domain misconfiguration. Even if all your Docker services are running correctly, the preview won’t work properly if Central is not set up with a fully-qualified domain name (FQDN) like central.example.com. Using just an IP address or localhost for local development can break WebSocket connections needed for Enketo to work; that is why @yanokwa strongly recommended using an FQDN for any Central deployment, even if it's just for local testing.
To fix this, set up a domain name (e.g., using a free DNS service like DuckDNS) map it to your server's IP, and update the DOMAIN variable in your .env file accordingly. After that, run docker-compose down and then docker-compose up -d to restart everything. Once this is in place, the form preview should work smoothly without throwing the “Could not connect with Form Server” error.
PS C:\> my-odk-central-xx.duckdns.org
Pinging my-odk-central-xx.duckdns.org [my-public-ip] with 32 bytes of data:
Reply from [my-public-ip]: bytes=32 time=5ms TTL=63
Reply from [my-public-ip]: bytes=32 time=5ms TTL=63
Reply from [my-public-ip]: bytes=32 time=5ms TTL=63
Ping statistics for [my-public-ip]:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 6ms, Average = 5ms
PS C:\>
Step 2: Map the newly created domain to the local machine
# Update the hosts file
127.0.0.1 my-odk-central-xx.duckdns.org
127.0.0.1 www.my-odk-central-xx.duckdns.org
Step 3: Update the .env file
# Use fully qualified domain names. Set to DOMAIN=local if SSL_TYPE=selfsign.
DOMAIN=my-odk-central-xx.duckdns.org
# Used for Let's Encrypt expiration emails and Enketo technical support emails
SYSADMIN_EMAIL=my-admin@my-domain.com
# Options: letsencrypt, customssl, upstream, selfsign
SSL_TYPE=selfsign
# Do not change if using SSL_TYPE=letsencrypt
HTTP_PORT=8099
HTTPS_PORT=4433
Step 4: restart the docker engine, rebuild the docker-compose
Your myodk.local.net configuration will not work because the Enketo container doesn't have a mapping from myodk.local.net to your IP. Here's what I would do..
Remove the DNS changes you made to /etc/docker/daemon.json and restart Docker.
cd ~/central
docker compose stop
systemctl restart docker
docker compose up --detach
Connect to the Enketo container and run the following to check if Enketo can reach Nginx. You should get a 1 output on the curl command if it's working.
# connect to enketo container
cd ~/central
docker exec -it central-enketo-1 bash
# install curl
apt update
apt install curl --assume-yes
# run curl. 1 means everything is working,
curl --silent --insecure https://myodk.local.net | grep --count getodk.org
# clean up
apt remove curl --assume-yes
apt autoremove --assume-yes
Try adding a host mapping to your docker-compose.yml. Replace x.x.x.x with your private IP. What this does is add a /etc/hosts mapping to your Enketo container.
@yanokwa, assume the domain we use the myodk.local.net and mapping to the hosts file: 127.0.0.1 myodk.local.net, the fully qualified domain for my local, not the public domain
Unfortunately, the following command returns 0, not 1
I'm not sure that the way our IT department configures our laptops could cause problems.
We are thinking about deploying the ODK-Central-Dev Env to Azure.
If you want a dev environment for playing around with ODK (e.g., trying features and APIs), then deploying to Azure as you've suggested is going to be your best bet.
@yanokwa , Does this branch include the front end? At this time, we want to have all the service packs together unless you have documentation to set up the front-end and integration with the backend.
