Data Disappears After Restart in Develop Mode on Cloud Run with CloudSQL Postgres

[Nao_Saino]

Hi,

I am new to Strapi and currently running it on Cloud Run with CloudSQL Postgres as the database.

I understand that there are develop and production modes in Strapi, and that in the production mode, operations such as adding collection types are not possible. However, in the develop mode, even though I can add collection types and entries, they disappear from CloudSQL once I restart the container.

Is this a feature of Strapi’s develop mode or could it be an issue with my setup? Could anyone guide me on how I could add data in a way that it persists even after a restart?

Here is the process I followed to set up:

1. I created a new Strapi application on my local machine using the command npx create-strapi-app@4.5.4 strapi --quickstart.
2. I then modified the database configuration file at /config/database.js to connect to my CloudSQL Postgres v14 database.
3. I built a Docker image from this setup.
   cloud builds submit --tag gcr.io/mygcpproject/strapi
4. Lastly, I deployed this Docker image to Cloud Run.

Thank you for your help in advance!

[dallasclark]

1. In /config/database.js, what is the value of connection.client?
2. In the /config folder, do you have separate folders for different environments?
3. To confirm, what database is shown in the logs when the Strapi starts?
4. Just to confirm when you say “restart,” you’re restarting the Google Cloud Run container only and it’s set up to connect to the existing PostgreSQL Database?

[Nao_Saino]

Hi dallasclark
Thank you for your reply

here is the content of my /config/database.js. The value of connection.client = postgres.

module.exports = ({ env }) => ({
  connection: {
    client: "postgres",
    connection: {
      host: env("DATABASE_HOST"),
      port: env.int("DATABASE_PORT"),
      database: env("DATABASE_NAME"),
      user: env("DATABASE_USERNAME"),
      password: env("DATABASE_PASSWORD"),
      ssl: env.bool("DATABASE_SSL", true),
    },
    debug: true,
    acquireConnectionTimeout: 1000000,
    options: {
      pool: {
        min: 1,
        max: 10,
        acquireTimeoutMillis: 900000,
        createTimeoutMillis: 900000,
        destroyTimeoutMillis: 900000,
      },
    },
  },
});

2. In the /config folder, do you have separate folders for different environments
   No, I don have any folder in the /config folder

I’ve taken a brief look at the logs when Strapi starts up, but I can’t seem to find the name of the specified instance. I am currently investigating this in more detail.
However, after adding a collection type in develop mode, I confirmed that the table has been created in CloudSQL by logging in and executing the \dt command. Therefore, I believe that the connection to the database is successful.

Accutualy, I have set the minimum number of cloud run instances to zero (cold start). This means that in addition to restarts that happen when I execute commands such as gcloud run deploy , restarts also occur after a certain period of inactivity or when there are no requests. It seems that in develop mode, data deletion also happens during these restarts.

[dallasclark]

The table generation in the PostgreSQL instance should be sufficient to validate you have a connection to the right database.

The container turning off and starting again later should not reset your database.

Just checking, the CloudSQL instance never terminates or anything like that? When the container is not running, the Google SQL Instance is still running and new containers will connect to the same SQL instance?

[Nao_Saino]

thank you again

The CloudSQL instance never terminates, and the container always connects to the same instance.

My hypothesis is that when Strapi starts up in develop mode, database migration is performed based on the configuration file in the docker image. I suspect that tables added by the user from the GUI might be deleted upon startup because only the default tables exist in the database at the time of the image build.

For your help, I will write the Dockerfile below.

FROM node:14 AS builder

RUN groupadd -r strapi && useradd -r -g strapi strapi
RUN apt-get update && apt-get install -y build-essential

WORKDIR /my-path

RUN chown -R strapi:strapi /my-path
RUN mkdir -p /home/strapi/.npm && chown -R strapi:strapi /home/strapi/.npm

COPY ./package.json ./
COPY ./yarn.lock ./
RUN chown strapi:strapi ./yarn.lock

USER strapi

RUN yarn install
COPY --chown=strapi:strapi . .
ENV NODE_ENV production
RUN yarn build

FROM node:14

WORKDIR /my-path

COPY --from=builder /my-path .

ENV PORT 8080

EXPOSE 8080
CMD ["yarn", "develop"]

[dallasclark]

It’s a misunderstanding of how Strapi works in development mode. When you start the server in development mode on your local machine and perform some changes through the GUI, you will see it will generate new files in your Strapi’s directory.

After you launch a docker image, the file changes made on that server are destroyed when the server instance is terminated. The next time the image is launched, it uses the original image (before the code changes).

In short, use development mode locally and push your code changes up to a CI/CD pipeline if you can. If you can’t run it locally, have 1 single server executing the code changes (very important) and make sure you pull down those code changes regularly.

Hope this helps.

[Nao_Saino]

I understand that the cause is that the migration files generated on the container are not being retained. Your advice is very helpful. Thank you.