Hey Hunter, thanks for the write up.

I’m working my way through it and have come up against this possibility which I wonder if you could comment on:-

I actually have the nginx in Bitnami Launchpad for Google Cloud Platform (not the MEAN stack)
and mongodb in Bitnami Launchpad for Google Cloud Platform each in their own instances with their own buckets.
Each are micro instances and nginx uses a solid state disk.
I have your script that will upload and deploy meteor into another instance, created through the GCE console using Instance Templates → Instance Groups → Instance

(Some of those settings are unclear how to set to me, but I’m willing to experiment.)

At the moment this script will install nginx into the same instance.
I’m thinking it would be better to use the bitnami installed instance of nginx.
For mongodb I assume I just have to set the correct MONGO_URL value using the internal address of the mongo instance.
What should parameters be for nginx and meteor so that they ‘know each other’ on deploy?
As given the script also references 
1.
gsutil cp startup.sh gs://$PROJECT/scripts/meteor_startup.sh
gsutil cp nginx.conf gs://$PROJECT/config/nginx.conf
gsutil cp ../app-secure/app.pem gs://$PROJECT/secure/app.pem
gsutil cp ../app-secure/app.key gs://$PROJECT/secure/app.key

in meteor_deploy.sh

and
2. after installing nginx
mkdir -p /etc/nginx/ssl
gsutil cp gs://$PROJECT/secure/app.pem /etc/nginx/ssl/app.pem
gsutil cp gs://$PROJECT/secure/app.key /etc/nginx/ssl/app.key

in meteor_startup.sh

From reading through the write up I understand that app.pem is the certificate file and app.key the key file, both of which I have created.
However, for my intended configuration obviously these lines are incorrect.
I would have to change 
gsutil cp nginx.conf gs://$PROJECT/config/nginx.conf
to
gsutil cp nginx.conf gs://$NGINXPROJECT/config/nginx.conf

I think that means app.pem and app.key would have to deploy into the same instance NGINXPROJECT, too?

I would appreciate any pointers in this.

BTW I’d love to go one step further into a continuous deploy scenario, syncing with local changes being ideal.