How to Login on Self Hosted Instance

[arvindgaba]

What is the default ID and Password after you use the YML to install a self hosted auto-installation.
How can we create the user, please help I would like to get started.

[gorkem-bwl]

You should see a registration page where you create your username and password, which will be the first account in the system as admin. From that point, you can login with the account created, and also invite other users to your dashboard.

If you only see a login page right after deployment, probably your server is not running, and frontend cannot reach out to the server then.

[arvindgaba]

Just redeployed, goes straight to http://192.168.0.97/login page, no registration page is there.

[arvindgaba]

Manually went to http://192.168.0.97/register and trying to register.

Gives Network Error after trying to login. Any suggestions?

[gorkem-bwl]

Did you make any changes to yaml file? I would try just using vanilla docker compose with the provided docker compose file and see if it works.

[ajhollid]

@arvindgaba if you host your backend at some location other than localhost:5000 you need to specify in the docker-compose file where you have hosted backend, otherwise the frontend does not know where the backend is.

You specify the location here:

services:
  client:
    image: bluewaveuptime/uptime_client:latest
    restart: always
    environment:
      UPTIME_APP_API_BASE_URL: "http://localhost:5000/api/v1"
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - server

update the UPTIME_APP_API_BASE_URL variable to point to your server.

[arvindgaba]

Did you make any changes to yaml file? I would try just using vanilla docker compose with the provided docker compose file and see if it works.

I used the default yaml file, this issue is after using it vanilla.

I am hosting both backend and front end in the same location. Let me change the localhost with the ip address and see if that makes any difference.

[arvindgaba]

It worked after changing the localhost to its own ip address. Thank you for your help. I need to now configure email smtp for alerts.

[gorkem-bwl]

Great! Let us know how it goes!

[ajhollid]

@arvindgaba if you wouldn't mind sharing some details about your setup that would be great too, it would be good to know why localhost doesn't work for you so we can figure out a solution 👍

Any details would be helpful, hardware, network, etc

[scarllin]

What is the default ID and Password after you use the YML to install a self hosted auto-installation. How can we create the user, please help I would like to get started.

I've already solved this problem.My experience was that just replaced the localhost to YOUR OWN SERVER IP.

[nicholas-a-guerra]

I'm new to Checkmate and just trying to get it up and running. Starting a test deployment on a server so needed to change the port forwarding to not be global as to not bypass local firewall. With that said, I am able to access the client interface via the browser, but still very unsure how to create the default user or if there are any underlying problems. I'm not noticing anything that stands out in the docker logs. Within each container I can ping the other containers. Is there documentation about the initial user setup? I can't seem to find anything.

[gorkem-bwl]

I feel like there are no issues here but @ajhollid can provide more information.

As per update the UPTIME_APP_API_BASE_URL variable to point to your server. suggestion above, did you double check that it points to your server? If so, I am out of ideas, but Alex can have a look at this tomorrow.

(My response was for your previous answer, not sure about about the screenshot)

[nicholas-a-guerra]

That's perfect, I'll keep trying a few things and look forward to hearing from @ajhollid tomorrow. Thanks!

[gorkem-bwl]

Sure. Most of the time it's either a connection or a configuration issue/overlook :)

[nicholas-a-guerra]

Undoubtedly. Just for another point of data. I realized wget was probably a bad idea, but instead curl was probably a better hint if at least the connection was there. And from what I see it seems like the connection is good. So now I think I'm more unsure of the issue.

[gorkem-bwl]

OK :) Pretty sure it'll be resolved tomorrow

[ajhollid]

Hey @nicholas-a-guerra,

We need to know a little bit about your setup to be able to help.

The issue is that your Client and Server are both running, but the Client cannot talk to the Server.

This is almost always because the base API url is set to the wrong value.

Are you running via docker compose? If so, you should set the api url in the docker compose file.

If you are running local development servers for client and server then you should set the api url in the client's env file

[ajhollid]

@nicholas-a-guerra no problem!

I realize it's a bit confusing as the config lives in docker compose, it makes a certain amount of sense to assume it's meant to be used in the docker network.

In fact all the client docker image does is run an nginx server that serves the react app to your browser when you request it, everything from there on out happens in your browser.

The only reason we even include the variable there is for users that want to run the client on one machine and the server on another, which happens now and then.

I hope that helps explain what's going on and helps you get up and running!

[nicholas-a-guerra]

Just had another thought and don't want to forget to ask. But I don't expect a response so late tonight haha.

I understand now why it wasn't working but also still a little unsure about the intended setup. So if the api url needs to be able to gain access via the browser, then won't localhost also not work? It would need to be the ip of the server, correct? Even if the client and server are on the same host, because the browser will be on a different host. Or maybe there is something I'm still missing there.

Then a follow up. Right now we use caddy as our reverse proxy for a few apps. This would likely be what we do for client. But how do people typically secure the server port 5000 connection, since this is separate? Would it need its own reverse proxy?

Sorry for being naive here, I work with a lot of simple apps that just have the client facing port and all the other connection occur docker to docker. So this methodology is new to me.

[ajhollid]

Hi @nicholas-a-guerra ,

The typical setup is a hobby user self hosting on their own machine.

That means that browser and Server are usually on the same machine, this is why kcoalhost works.

If you deploy to a remote server, now browser and Server are not on the same machine, so if this is your setup then you are correct, you need the Servers address for your api URL.

And yes to your second question, if you need to put the server behind a proxy for safety then you would need to provide access to port 5000.

Hope that helps 👍

[nicholas-a-guerra]

Oh interesting, this seems like a very robust app for the typical install to be all local.

Well I think this may add a huge amount of complexity then unfortunately, if I'm understanding this correctly. Client connection will be secured through a proxy and authenticated. But now the server access can be behind a proxy but won't be authenticated? Unless the client does appropriately authenticate to the server? But then the comms must be https or authentication would be in plain text. It seems like an interesting deployment because so many apps just have one port that you expose and the backend takes care of itself (i.e. Grafana, Portainer, Healthcheck.io, etc).

[nicholas-a-guerra]

@ajhollid, does that mean the team member feature is rarely used? Wouldn't a team member need to access from a different host and therefore the localhost configuration would not work if anyone that has more than one user? Just trying to get a better idea of who this is designed for so I know if it could be a good product for our company.

[ajhollid]

Hi @nicholas-a-guerra ,

I'm not sure I'm understanding the issue here. Access to the server always requires authentication, you cannot access any sensitive endpoints of the server without an access token.

The client is simply an interface to the server. In any web applicatoin the client is always assuemed to be insecure and compromised as we have no control over it. All authentication happens on the server end.

[nicholas-a-guerra]

@ajhollid No issue, I just wasn't exactly sure how the backend interacted with the front end. Seems like with 2 reverse proxies, one for the client and one for the server, it should be reasonable. Just different than what I've seen from other small applications.

Well I appreciate all the support. Still undecided right now as I think there are 2 features that would be really helpful. One is slack notifications. And the other would be "reverse ping" monitoring. Basically allowing an application to post to a url that hits the server and keeps a monitor up. Then missing the post by a threshold time would count as down (this is used for things like cronjob monitoring by apps like uptime kuma and healthchecks.io)

[gorkem-bwl]

Slack/Telegram/Discord notifications will be there in the next release.

Reverse ping is interesting. Can you create an issue for this so we won't miss it? (together with your description and use cases)?

Are there any vendors providing this functionality as well, so we can have a look too?

[nicholas-a-guerra]

Uptime kuma and Healtcheck.io both have this feature and are very widely used. Essentially just need a way to track cron jobs. The most universal way to do this is to generate a custom url to be able to be post to.

[ajhollid]

@nicholas-a-guerra yes the basic idea is that the front end and the backend are totally ignorant of each other, you can host them however you like. Flexibility is key for us, but we also try to provide an out of the box solution for hobby users wanting to run on their own with minimal config.

The backend is a RESTful API so you can interact with it with any client you like really. You can use the whole application via cURL if you wanted to. You don't have to use our Frontend at all.

I like the idea of reverse ping, that is a useful feature and I think we can build that in to a future release!

[gorkem-bwl]

@nicholas-a-guerra wondering if you have been able to install? (ignoring the two features you mentioned)

[nicholas-a-guerra]

Hi, thanks for checking, yes I was able to get it installed and connected successfully. Everything looked good. Still deciding how to move forward. I think those 2 features are the most important for our use case. So likely we'll need to wait and see once your team is able to get to those. Thanks for all the help!

[gorkem-bwl]

OK - good to know. At least one of them will be solved in this version, and let me look at how to get the other one work :)

[aeonoea]

Sorry to hijack this thread but I have a similar issue, in that the client is not able to connect to the server.

I've used the default docker compose and just changed the exposed ports since of course 80/443/5000/6379/27017 are already used by various other apps. The project runs fine and the logs don't show any issues. I've also tried disabling the firewall.

Although I have put the new exposed port (5050) in the 'UPTIME_APP_API_BASE_URL' env, it won't connect and I get the usual Network error when trying to log in via web app. What I've tried as values so far:

• http://localhost:5050/api/v1
• http://{local-ip}:5050/api/v1

Also I've tried making use of the docker network:

• http://server:5000/api/v1
• http://{docker-ip}:5000/api/v1

Any help is appreciated!

[gorkem-bwl]

@ajhollid This one is for you :)

[ajhollid]

Hey @aeonoea,

Could you share the contents of your docker compose file?

Also the contents of your server.env file?

I imagine there's a port that isn't defined correctly in there some here, those files will help us track it down.

[izonejangwonyoung]

I'm in the same situation....

[aeonoea]

@ajhollid

Thanks for looking into it! I am using the quick start method (for users) so I don't have a server.env file. May that be the issue, when changing the exposed port from 5000 to something else? Anyways, here's my compose file:

services:
client:
image: bluewaveuptime/uptime_client:latest
container_name: checkmate-client
restart: unless-stopped
environment:
UPTIME_APP_API_BASE_URL: "http://server:5000/api/v1"
ports:
- "4050:80"
- "4053:443"
depends_on:
- server
server:
image: bluewaveuptime/uptime_server:latest
container_name: checkmate-server
restart: unless-stopped
ports:
- "5050:5000"
depends_on:
- redis
- mongodb
environment:
- DB_CONNECTION_STRING=mongodb://mongodb:27017/uptime_db
- REDIS_HOST=redis
# volumes:
# - /var/run/docker.sock:/var/run/docker.sock:ro
redis:
image: bluewaveuptime/uptime_redis:latest
container_name: checkmate-cache
restart: unless-stopped
ports:
- "6380:6379"
volumes:
- ./redis/data:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 30s
timeout: 10s
retries: 5
start_period: 5s
mongodb:
image: bluewaveuptime/uptime_database_mongo:latest
container_name: checkmate-db
restart: unless-stopped
volumes:
- ./mongo/data:/data/db
command: ["mongod", "--quiet"]
ports:
- "27018:27017"

To access the web app I then reverse proxy into port 4050 which works great.

[ajhollid]

Hey @aeonoea,

Sorry for the slow response, thanks for posting your data.

You don't require a server.env for the quickstart, your ports appear to be mapped correctly.

I believe your issue is here:

UPTIME_APP_API_BASE_URL: "http://server:5000/api/v1"

This is the URL that your Client uses to connect to the Server.

Your Client runs in your browser, not your Docker network, so you cannot use docker container names to connect to the server.

You should use http://localhost:5050/api/v1 in order to connect. This is assuming of course that your server is running on the same physical machine.

[aeonoea]

Thank you for the explanation, it works now!

Since my project runs on a Synology in a different location and with a fixed ip, own domain and certificate, it means that I also have to expose the server port and set the variable to:

UPTIME_APP_API_BASE_URL: "https://checkmate.domain.tld:5055/api/v1

I didn't want to use http over the web so I set up a reverse proxy for the server port as well.

[aeonoea]

As an afterthought, I can imagine most people use a similar setup and might run into the same issue.

I might be mistaken but most web apps I've come across connect to the backend internally via docker network, so maybe it's worth pointing out boldly in the documentation that with Checkmate this is not the case, and the client connects via browser to the server.

Thanks again for your help and this amazing app!

[gorkem-bwl]

@aeonoea you are right - we'll take care of this - sometimes we may not be in a situation to grasp/take into consideration different setups and requirements, but rest assured, we'll fix this in the document.

Thanks for your kind words, as well :) That means a lot to us!

[ajhollid]

Hey @aeonoea,

Great to hear that everything is working now!

As for other applications, I can't speak directly to that as I don't know exactly which ones you are referring to, but any Client that runs in your browser by definition does not have access to the Docker network.

I can see how one could be confused however, as there is a "client" docker image. In fact, all that Client docker image does is run an nginx server that serves the Client to your browser. After that everything is happening in the browser.

Hope that explanation didn't bore you 😂 Long story short as @gorkem-bwl we will definitely add some documentation around this, you are correct your use case is more common than we expected so we'll make it a priority to make it clear for everyone.

Thanks your your insight and trying out the app, keep your eyes open for more cool features and updates!

[aeonoea]

@ajhollid Absolutely not, thanks for explaining! If it would bore me I wouldn't be here at all 🙃

I also see now the function of the client container, if it's a nginx server. In principle, would it also be possible to leave the client out of my docker compose, only expose the server port and use my own nginx proxy? Because now I run my own nginx proxy (built-in to the synology) to connect to the client which is also a nginx server which then connects to the backend.

[ajhollid]

@izonejangwonyoung if you can also share your docker compose file I'd be happy to take a look.

[slimshizn]

I've done what everyone is suggesting here, but am still running into an issue. Seems that the local IP (Server IP:5000) is causing a CORS issue with login and throws the same network error.