Planetscale connection

Anybody has achieved Planetscale connection using Fly.io? Tried it several times but I cannot make it work. Tried setting the certificate authority (added the ca-certificates package on dockerfile south out luck. Any example out there that can help? Thank you!

Can you share your dockerfile? What error messages are you seeing?

Well sincerely I dont know why but now it is working with a new launch from 0. The error was about the certificates, thats why I thought I could be doing something wrong. This is my dockerfile in case someone wants to connect to Planetscale with Prisma from Fly:

# base node image
FROM node:16-bullseye-slim as base

# Install openssl for Prisma
RUN apt-get update && apt-get install -y openssl && apt-get install -y ca-certificates

# Install all node_modules, including dev dependencies
FROM base as deps

RUN mkdir /app
WORKDIR /app

ADD package.json package-lock.json ./
RUN npm install --production=false

# Setup production node_modules
FROM base as production-deps

RUN mkdir /app
WORKDIR /app

COPY --from=deps /app/node_modules /app/node_modules
ADD package.json package-lock.json ./
RUN npm prune --production

# Build the app
FROM base as build

ENV NODE_ENV=production

RUN mkdir /app
WORKDIR /app

COPY --from=deps /app/node_modules /app/node_modules

# If we're using Prisma, uncomment to cache the prisma schema
ADD prisma .
RUN npx prisma generate

ADD . .
RUN npm run build

# Finally, build the production image with minimal footprint
FROM base

ENV NODE_ENV=production

RUN mkdir /app
WORKDIR /app

COPY --from=production-deps /app/node_modules /app/node_modules

# Uncomment if using Prisma
COPY --from=build /app/node_modules/.prisma /app/node_modules/.prisma

COPY --from=build /app/build /app/build
COPY --from=build /app/public /app/public
ADD . .

CMD ["npm", "run", "start"]
2 Likes

Thanks for sharing your dockerfile. I’m glad it’s working for you!

Hey, I’m trying to connect in the same way but not getting anywhere. Do I have to add any config in the fly.toml? I’ve added the ca-certificates package to my Dockerfile, but doesn’t seem to make any difference. Here’s the error I’m getting:

Error: Error opening a TLS connection: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../deps/openssl/openssl/ssl/statem/statem_clnt.c:1924: (Hostname mismatch)

Has anyone else seen this before? Or know what to do to resolve it? Thanks so much!

If you have the ca-certificates installed correctly for me the error was with the connection string. Make sure you copy it directly from Planetscale to your secrets.

Thanks for your quick reply! I’ve got the package installed and redeployed onto a fresh app and still getting the same response.

Did you have to make any changes to the Dockerfile or fly.toml to allow the outbound connection? Or specify sslcert on the connection string? (Tried the latter but to no avail.)

Thanks again!

Hi Josh! No problem.

My Dockerfile is the one marked as the solution. My string is like this (I’m using Prisma so is the one I needed):

DATABASE_URL='mysql://***********:************@xxxxxxxxx.eu-west-3.psdb.cloud/app-db?sslaccept=strict'

My fly.toml file is this:

app = "app"

kill_signal = "SIGINT"
kill_timeout = 5

[env]
  PORT = "8080"
  NODE_ENV = "production"
  PRIMARY_REGION = "mad"

[experimental]
  allowed_public_ports = []
  auto_rollback = true

[[services]]
  internal_port = 8080
  protocol = "tcp"
  script_checks = []

  [services.concurrency]
    hard_limit = 200
    soft_limit = 150
    type = "requests"

  [[services.ports]]
    handlers = ["http"]
    port = 80
    force_https = true

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

  [[services.tcp_checks]]
    grace_period = "10s"
    interval = "15s"
    restart_limit = 6
    timeout = "2s"

Hopefully this is enough for you to find the missing parts or the errors. Double check everything.

2 Likes

Hey Eduard, really appreciate your help!

I’m sorry to say that I’ve got the same config and it’s not working for me. I’ll post them all below. This is a Remix app with the Blues Stack, only difference is using PlanetScale instead of Postgres. Did an initial build when I initialised the project as per the readme and it worked fine, so the issue is coming from trying to connect to PS.

Dockerfile:

# base node image

FROM node:16-bullseye-slim as base

# set for base and all layer that inherit from it

ENV NODE_ENV production

# Install openssl for Prisma

RUN apt-get update && apt-get install -y openssl && apt-get install -y ca-certificates

# Install all node_modules, including dev dependencies

FROM base as deps

WORKDIR /app

ADD package.json package-lock.json ./

RUN npm install --production=false

# Setup production node_modules

FROM base as production-deps

WORKDIR /app

COPY --from=deps /app/node_modules /app/node_modules

ADD package.json package-lock.json ./

RUN npm prune --production

# Build the app

FROM base as build

WORKDIR /app

COPY --from=deps /app/node_modules /app/node_modules

ADD prisma .

RUN npx prisma generate

ADD . .

RUN npm run build

# Finally, build the production image with minimal footprint

FROM base

WORKDIR /app

COPY --from=production-deps /app/node_modules /app/node_modules

COPY --from=build /app/node_modules/.prisma /app/node_modules/.prisma

COPY --from=build /app/build /app/build

COPY --from=build /app/public /app/public

ADD . .

CMD ["npm", "start"]

Fly.toml (updated as per your post):

app = "app"

kill_signal = "SIGINT"
kill_timeout = 5

[env]
PORT = "8080"
NODE_ENV = "production"

[experimental]
allowed_public_ports = []
auto_rollback = true

[[services]]
internal_port = 8080
protocol = "tcp"
script_checks = []

[services.concurrency]
hard_limit = 200
soft_limit = 150
type = "requests"

[[services.ports]]
force_https = true
handlers = ["http"]
port = 80

[[services.ports]]
handlers = ["tls", "http"]
port = 443

[[services.tcp_checks]]
grace_period = "10s"
interval = "15s"
restart_limit = 6
timeout = "2s"

[[services.http_checks]]
grace_period = "5s"
interval = "10000"
method = "get"
path = "/healthcheck"
protocol = "http"
timeout = "2000"
tls_skip_verify = false

Prisma Schema (as per the PS docs):

datasource db {
  provider             = "mysql"
  url                  = env("DATABASE_URL")
  referentialIntegrity = "prisma"
}

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["referentialIntegrity"]
}

Commands I’m using to deploy:
fly create app
fly secrets set SESSION_SECRET=$(openssl rand -hex 64)
fly secrets set DATABASE_URL="[Copied directly from PS]"
fly deploy .

Sorry for the long message. It’s a weird one as it seems it should work. Probably something simple I’m missing or not understanding.

Thanks so much for your help!

I think I faced a similar (or the same) issue and this is why I opened this thread. Appart from this I think I can’t help more… maybe @michael can take again this as there are some issues for people that tries to connect to Planetscale (maybe an official example could be useful?).

The only thing that I would do in your case is to unset the secret and set again making sure you generate a new password and copy the entire string from Planetscale directly to the secret (make sure you select prisma when it asks for the type of connection string). At least that was what helped me and I always thought it was my fault for not setting correctly the string.

Did you find anything @josh3?

Hey Eduard,

Thanks for your message. No unfortunately not… I’ve tried deleting the password and trying a new one a few times but getting the same thing… It would be great if @michael would be able to have a look at it as well. Thanks in advance for your help!

Hey all,

Just wanted to say I’ve managed to get it working now… As is the case most of the time, it was an easy fix (I’m new to Prisma, Fly & PlanetScale!!).

As I was using the Remix Blues Stack, it came out of the box with the Prisma setup to work with Postgres on Fly. This meant that it added the FLY_REGION to the DATABASE_URL at run time, hence the ‘Hostname mismatch’ error.

Removed that, and it worked perfectly.

Thanks for your help @edmbn, really appreciate your efforts!

1 Like

Hey! Nice to read that you found it. I always suspected that should be an easy fix but that don’t always mean it is easy to find. Happy to see everything is fine now.