Hi Guys,
I’ve just upgraded my Strapi project from v3.3.4 to v3.4. It’s going fine on my localhost, but the app crashed on Heroku. Where could the problem be?
I have never seen the following error message:
@lexcode Hello, Thanks for the quick reply!
How do I delete “.cache” folder on Heroku? “.cache” folder is supposed to be recreated every time the project is deploied again. My app runs normally on localhost. This problem only exists on Heroku.
But on Heroku I have a second Strapi project that doesn’t have this problem. I’m doing a database comparison.
I have been doing step by step since last spring when I started using strapi.
Today I did 3.2.0 to ver 3.4.0. Then 3.4.0 to ver 3.4.1
I would like to have a “fresh start” on my strapi installation. Is it possible to create a new strapi app and then copy stuff from the previous install ?
I just have tables and relations.
You can yes but if you are using relations there will be a bit of manual migration required to remap the relational IDs.
Heroku + Mongo Atlas inherently is insecure as you need to open your atlas security settings to the public web 0.0.0.0/0 as Heroku doesn’t provide a list of possible IP addresses their connections could come from, and that IP changes every time the dyno restarts. They offer an in-house PG add-on that lives inside their network, so less risk of a data leak.
Depends on what you are referring to, if you have a link to your project I could take a look.
Thanks a lot for your advice @DMehaffy
Updating the code and getting rid of whatever old stuff from beta releases was very simple. At the same time I switched from mongodb to postgres.
I created a new strapi project, selecting postgres as the database. Tested it and made sure it worked fine.
Then copied the ./api and the ./components from my previous strapi into the new.
I needed to rebuild strapi using the cli and it worked fine
I’m using graphql to access strapi data and I found that all my code worked just fine. The only change I have found so far is that in mongodb the date field was named updatedAt and in postgres the same field is named created_at.
Yup back in the day this was “intended” but moving forward we are starting to use snake_case for all the injected fields. Most likely in v4 we will finally do the breaking change for Mongo users and move them from:
AWS Aurora itself is a proprietary database built and maintained by the AWS team. It’s not a database we directly support thus we can’t promise it will even work there.