I created an EC2 linux using the AMI provided here: https://redash.io/help/open-source/setup#-Setup and I can log into the linux instance with Putty or WinSCP, but I cannot get the landing page for redash using the DNS as explained in Setup. I updated the security rules to allow inbound SSH, HTTP, HTTPS and am using a key pair I generated on AWS when using Putty and WinSCP. I’m unclear what I’m missing to get the account setup.

What message do you see when you try to connect? A few ideas:

If you see a 500 error
The server is receiving traffic but something went wrong.

If you see a 404 error
The server is receiving traffic but doesn’t know how to find Redash.

If you see a generic “could not connect to host” error
Then it’s probably an issue with DNS and your container isn’t receiving network traffic

Here is what I get when I hit the public DNS. But when I SSH in there are no issues.

Hmmm what happens if you visit it using its domain name instead of the IP directly?

Sometimes it just says connection refused, sometimes I get this:

Progress! This page means the nginx reverse proxy is functioning, but the Redash server itself isn’t actually responding. Are you certain the the container that runs Redash (called server in your docker-compose.yaml) is up and running?

This is a pre-built AMI from redash, so I don’t have the yaml. I looked at the AWS logs but am unsure what I’m looking at, and I’m logged into the linux instance but don’t know where to look there.

I might see an issue–they suggest t2-small, but I launched the default t2-micro. I think I’ll shut it down and try again.

Rebuiding using t2-small has fixed it

1 Like

@eafpres thanks for letting us know how you managed to resolve this. I think what has probably happened is that the t2.micro instance did not have enough resources to start all the containers (services) that Redash relies on hence it did not respond when you tried to browse the home page. The minimum recommended RAM for the Redash AMI is 2GB, which means a t2.small instance or better. In my experience you’ll probably find you need at least a t2.medium once you get any significant usage going.

1 Like

I have this same problem, but using t2.small and t2.medium does not fix it.

My suggestion would be to spin up something big and if it works then work back to find the size you need. To spin one up and test won’t cost much.

1 Like

We are trying to launch an AWS Image as well and getting a similar issue. Where after launching the EC2 instance the page takes a long time to load and will time out.

Are there any known issues with the current images?

1 Like

Not aware of any issues with these images. But testing this is on my agenda for the next couple of days. Our working plan until we update the images for V10 is to recommend deploying the V8 images and then upgrading them like normal. If there are issues with the images, however, then this plan requires adjustment :frowning:

3 Likes

Roger, let me know if we can do anything.
We tried several different EC2 sizes with the same result. I can ssh into the instance but appear there just isn’t anything loaded on them. The ubuntu instance requested a reboot, but same issue even after a restart.

Have you tried upgrading to the V10 image in your docker-compose.yaml file? Also, what do you see in the logs for these instances? Did any of the services even start?

We are using the AWS instances from this page

Looks like they are still v8, is there an update AMI for v10?

When we ssh in I don’t see any logs and looks like no services are started. Actually looks like the instance is just a clean ubuntu instance with nothing on it

I’ll reiterate what I wrote above

Our working plan until we update the images for V10 is to recommend deploying the V8 images and then upgrading them like normal. If there are issues with the images, however, then this plan requires adjustment

Sounds like the V8 image just didn’t work for you. I will need to see if I can reproduce in my own AWS account…

Alright, I have verified the V8 image works. I think the issue you have is you didn’t configure an inbound security group rule to access the instance. If you don’t do this it will appear as though the instance didn’t start.

1 Like

I’m facing the same issue after setting up inbound security group.
Could you please elaborate on the fix?