Hi Daniel,
I use automatic scaling with 1 max-instances in my dev project. This is one thing that helps to limit the costs of the dev environment.
I also debug and test the app locally first, before I deploy anything to GAE. In your case with
Node.js flex:npm start
You can do this in Cloud Shell, too.
Another measurement was to use a different app.yaml and cron.yaml in dev project than in production project. In app.yaml I define auto-scaling with max-instances 1 and F1 (because 28 hours of F1 are free in standard environment). Although there is no free tier for flex instances, you still can define cheaper virtual machine types for dev. Cron-job tasks are scheduled far less frequently than in production, because I typically debug/test them by triggering them manually and I don't need them to actually run in dev project in contrast to production.
You probably also want to make sure that in dev (!) project, with every new deploy every previous version is stopped and the new version is promoted to default version, e.g.:
gcloud app deploy app.yaml --promote --stop-previous-version
See the
gcloud app deloy reference for details. Alternatively, you could overwrite an existing version, by specifying the version to replace:
gcloud app deploy app.yaml --version=v-ani-dev
This would also work with multiple devs deploying to the same dev project, although I usually would go with one dev project per dev. Then also have a QA project where you can deploy and test release candidates before they are deployed into staging or production. (Basically, dev -> qa -> staging -> production)
One last thing: I do not use production data in dev or QA (for cost reasons, but also for security reasons). Instead I would use only a small subset of fictive sample data that reflects the nature of the production data. You always can use import/export features of Cloud Datastore, Cloud SQL etc. to restore sample data if for example you debug a new feature that changes schema. And only provide production data to the staging project (using export/import again) if you need to test that a migration will run successfully through your entire production data. That can be quite expensive though.
Hope that gave you some ideas.