Does this project run? Can I get paid support to set up self-hosted?

Right now Temporal seems mostly fraudulent to me, however I still have hope. To summarize: I’ve tried A LOT to get it running but haven’t had success. This, among other things, makes future interactions with this project extremely concerning.

:cross_mark: The canonical Docker Compose example fails to start
- git clone + docker compose up
- tried multiple repo commits and temporal images
- tried multiple environments
- [Bug] Project does not run - Temporal server rejects all connections · Issue #225 · temporalio/docker-compose · GitHub
:cross_mark: The canonical binary deployment fails to start
- How to Configure a Temporal Service without a Proxy | Learn Temporal
- journalctl shows the Temporal logs with the errors
:cross_mark: context deadline exceeded meme error handling
- There isn’t much I can do to fix the canonical examples without becoming a full-blown Temporal expert; extremely high barrier to entry
:cross_mark: The Docker image fails to build
- The instructions in the repo DO NOT WORK
- To be fair, let’s call this a documentation issue, it looks like there are just some missing steps
- Building this won’t really help me much anyway so I’ve moved on
:white_check_mark: The dev server works great, and can be hackishly deployed. At least I know my workflows are doing great!!

I am building a project for a startup to be self-hosted in many cases. This means, that should I be able to choose Temporal, any customers of ours will also be deploying it - high net good. We will be making them aware of the Cloud offerings, but firstly need to make available a low-end option (self-host Docker Compose Temporal). I am trying so hard to use this project, but it resists me.

  • Canonical examples do not run (first and major red flag)
  • 500 open issues including EOL dep upgrades (AWS Go SDK v2) and CVEs
  • Very large code base (well, naturally), probably needs significant refactoring. Sure.
  • All leading to: Appears under-maintained, or needs maintainers. Common for open-source, but there should be some money behind this.

For now I want the simplest deployment possible. Really, the canonical Docker Compose. One container for server, one for UI, using a Postgres container for both the default and visibility stores. auto-setup is fine. Minimal config.

I’d even be considerably pleased with getting the binary to work. Not an end goal, but a huge first step, just getting Temporal working in a production environment.

Does anyone have any paid support offerings, feedback, ideas, GUIDES THAT WORK, config recommendations, or similar stories? As the days go on trying to run this, it is becoming harder and harder to believe that I am completely alone.

I can and will provide exact reproductions in any clean environment but it’s almost unfathomable that these issues are difficult to reproduce. git clone + docker compose up. Does this actually work for anyone? Even reassurance that ‘yes, a Docker Compose example works for me’ is great.

There are “escape hatches” for me to develop with - dev server / free startup Cloud credits - but this isn’t just about me developing our code, it is about me being able to put my faith into this project as a tech stack decision that is something of quality I feel comfortable sending to customers with my word.

I will even open a pull request with an updated Compose setup or binary deployment guide, if there are more current steps for setup that we might uncover here. Man, give me a break.

Have been running compose GitHub - tsurdilo/my-temporal-dockercompose: Temporal Server setup for Docker for quite a while now and works fine for smaller size workloads. Wondering what specific issues you were running into with compose so far?

1 Like

I was getting the dreaded context deadline exceeded / connection refused from the SDK, from the CLI in the admin-tools container, and even from the CLI local to the server container. This was despite what seemed in all aspects to be good networking (verified with nslookup, nc, ping, ss, etc), not to mention it’s literally as-is from temporalio/docker-compose.

Thank you for pointing me to this community project one more time; I will absolutely take your advice. The duality between the official Compose project and the community one is confusing. To be honest at first I couldn’t take seriously a project with a 500-line Compose file, that specifies an image with the architecture in the tag name image: gcr.io/cadvisor/cadvisor-arm64:${CADVISOR_IMG}, and defines ports like { published: 7233, target: 7233 } instead of 7233:7233. Besides that, I was looking for a minimal starting example I could then make more complex, not the other way around. It’s very bad for learning curve.

Despite that, maybe simply by improved documentation, I immediately notice this:

$ docker exec temporal-admin-tools tctl cl h
temporal.api.workflowservice.v1.WorkflowService: SERVING
$ docker exec temporal-admin-tools temporal operator cluster health
time=2025-04-26T20:59:38.445 level=ERROR msg="failed reaching server: context deadline exceeded"

What is with this “new” CLI? Yes, the version is 1.2.0…

I notice an address option. --address=temporal-history:7234 gives context deadline, but replacing the Docker DNS name with the IP gives a different error, which might be an improvement! level=ERROR msg="failed checking cluster health: health check error: unknown service".

My goal is now to verify this example works, collapse the isolated temporal services back into one container, and otherwise incrementally change the configuration until it slowly becomes what I need. I will report back with my findings.

OK here we go: both official and community configs work

There are 2 major points here. Both can be summarized as ‘Temporal is extremely bad at Docker networking’.

  1. The temporal command line tool does not work. The tctl command line tool works.
  2. The Temporal Go SDK is incapable of resolving Docker container DNS. However, when looking up the IP using nslookup temporal, then using the IP directly in the “host port” option, that does work.
  3. Bonus: The world of difference in command line tools is also somewhat related to failure to resolve Docker DNS, as shown by the experiment in my previous reply.

Final note: The official Temporal Docker Compose repo has 0 documentation on how to verify the deployment, UNLIKE the community one which clearly states ‘if you do tctl cl h that should work’. Without that note I defaulted to temporal operator cluster health. Even this minor difference in documentation was enough for me to finish my debugging. Damn, that’s sure something to waste a week on.

Thank you so much @tihomir

Since this appears to be the result of multiple bugs, NOT documentation (the CLI and Docker networking should work in the ways I expected), I do not plan on making any pull requests. This thread is enough. If instead failing to resolve Docker DNS is somehow intended behavior, I will make a documentation PR. Nothing from the guides to the API docs suggest this.