@aonnikov you beat me to it, most of the fixes you just pushed I have laying unpushed on my machine 😅
It would have been nice to get a co-author on your commit, considering the issue was initially raised by me and has been fixed in this PR.

@aonnikov you beat me to it, most of the fixes you just pushed I have laying unpushed on my machine 😅 It would have been nice to get a co-author on your commit, considering the issue was initially raised by me and has been fixed in this PR.

Fair enough, added you as a co-author (know, it is dirty but better than nothing). Much appreciate your contribution!

@aonnikov there are a lot of duplicate env variables set in the compose.yml, LAST_NAME_FIRST under transactor for example.
Are they really all used?

Finally achieved a working huly instance!!

@aonnikov there are a lot of duplicate env variables set in the compose.yml, LAST_NAME_FIRST under transactor for example. Are they really all used?

Yeah, all of them are used, but some of them are not mandatory and can be omitted.

@Sharlyll This PR is meant to fix all the issues with the main branch. Please try the nginx branch on
https://github.com/veryCrunchy/huly-selfhost and let me know if that fixes things for you!

git clone -b nginx https://github.com/veryCrunchy/huly-selfhost.git

git clone -b nginx https://github.com/veryCrunchy/huly-selfhost.git

Hi
I still get the same error (unknown error. load failed) even after using git clone -b nginx https://github.com/veryCrunchy/huly-selfhost.git
Please can you give a step by step?
Perhaps I am missing something.
I have tried both arm64 and amd

Thanks in advance

@Sharlyll follow these steps: https://github.com/veryCrunchy/huly-selfhost/tree/nginx
Instead of git clone https://github.com/hcengineering/huly-selfhost.git run the command in my previous comment

I still the same issue with account service not available. My configuration:

Configuration Summary:
Host Address: localhost:${HTTP_PORT}
HTTP Port: 8081
SSL Enabled: No
Do you want to run 'docker compose up -d' now to start Huly? (Y/n): n
You can run 'docker compose up -d' later to start Huly.
Setup is complete!

@Sharlyll follow these steps: https://github.com/veryCrunchy/huly-selfhost/tree/nginx Instead of git clone https://github.com/hcengineering/huly-selfhost.git run the command in my previous comment

Thanks for your response.
These are the steps I followed to get a working Huly instance:

1. Update and upgrade server.
2. set hostname
3. Install Nginx
4. Install Docker (Followed the instructions here )
5. cd to directory ( in my case /var/www)
6. git clone -b nginx https://github.com/veryCrunchy/huly-selfhost.git
7. cd huly-selfhost
8. ./setup.sh (provide responses to the prompts. This is the important part. I noticed that the repo does not work when SSL is set to Yes. So choose No)
9. sudo ln -s $(pwd)/nginx.conf /etc/nginx/sites-enabled/huly.conf
10. Remove nginx default host file :
    sudo rm -r /etc/nginx/sites-enabled/default and
    sudo rm -r /etc/nginx/sites-available/default
    test nginx config: sudo nginx -t
11. sudo nginx -s reload
12. sudo docker-compose up -d

Huly should be up

I tested this out on my ubuntu instance and it works. I had to stop my nginx service on the server and leave the work to the docker nginx container.

What does this
read -p "Enter the port you want nginx to expose: " NGINX_SERVICE_PORT
refer to?

Is it referring to the port that most people would pick 443 or is it referring to where the "front" container is attached to, 8087 in the standard Huly setup?

What does this read -p "Enter the port you want nginx to expose: " NGINX_SERVICE_PORT refer to?

Is it referring to the port that most people would pick 443 or is it referring to where the "front" container is attached to, 8087 in the standard Huly setup?

443 would be for https, so if you have ssl certs, you could use this. The port you should use is most likely port 80, but you could use port 8080 or 80xx (some other number) if you want to use http://localhost:8080 or http://localhost:80xx (e.g. 8085). If you don't have any other web apps running, port 80 is best as you don't have to specify 80 in the url as it is the default.

We have no goal to provide production ready solution, the original intention was to provide a sample configuration for local deployment.

As a new user trying to get this thing up and running on a private server for my small company, this confuses me.

Is the self hosted solution viable or not ? Is it only for local use ?

I find it very weird that this repo is the self hosted solution, but then you say the goal is not for users to put new instances out there on the internet.

This pr makes the self hosted solution more viable. Whilst this repo prior to the pr gives the necessary resources for a technical user to be able to self host.
From my understanding the Huly team has no intent to upkeep the self hosted solution, especially for production environments. They do the necessary upkeep like version bumping.
It's up to the community to make the self hosted solution viable.

Wanted to say thanks to @veryCrunchy. I am up and running now and look forward to this being merged in as the basis going forward. I look forward to helping, as I'm able to, this project moving forward.

@shanzez do you run it on 80/443 port? I would be happy to merge this, because this PR solves most of the problems self-hosters usually ask, but the last time I tried to set it up locally, it did not work on custom port.
@veryCrunchy is that still true?

A custom port definitely works.
I do see the issue that's causing your instance not to work.

@aonnikov could you try this? (on linux for now, I believe mac still doesn't work)

Would a cli solution with Deno be accepted?
Would be much easier to upkeep and works on any platform

For now this pr can be merged.

@shanzez do you run it on 80/443 port? I would be happy to merge this, because this PR solves most of the problems self-hosters usually ask, but the last time I tried to set it up locally, it did not work on custom port. @veryCrunchy is that still true?

Howdy @aonnikov, we use:

    # Huly server configuration
    server {
        listen 443 ssl;
        server_name huly.<domain>;

        ssl_certificate /etc/nginx/ssl/huly.crt;
        ssl_certificate_key /etc/nginx/ssl/huly.key;

        # Front service
        location / {
            proxy_pass http://front:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

and we redirect port 80 to 443.

@aonnikov could you try this? (on linux for now, I believe mac still doesn't work)

I am running this on a Mac Studio M1, btw. Working great.

btw, in order to use the version 333 instead of 295, I did have to add some DB_URL's in. Some places I replaced MONGO_URL with it, and in one place I had both MONGO_URL and DB_URL. In the compose template file. I am now updated to 337 locally.

btw, in order to use the version 333 instead of 295, I did have to add some DB_URL's in. Some places I replaced MONGO_URL with it, and in one place I had both MONGO_URL and DB_URL. In the compose template file. I am now updated to 337 locally.

@shanzez thanks
I'm planning to bump version and update configs soon when I have a chance.

@aonnikov could you try this? (on linux for now, I believe mac still doesn't work)

Yep will try later.

Would a cli solution with Deno be accepted? Would be much easier to upkeep and works on any platform

Yeah, why not. The only thing, is that we are thinking about separating "official" and community-driven examples to give you guys more freedom with regards to what tools to use 😄 At this point not sure if it should be just a folder within the same repo, or separate repository. Any thoughts on this?

At this point not sure if it should be just a folder within the same repo, or separate repository. Any thoughts on this?

We shouldn't overcomplicate it. I think it's complicated enough as one repo already.