
This is a solid foundation for Cloud Run deployments that covers the practical stuff: containerized services, event-driven functions, and cold start optimization with startup CPU boost and min instances. The patterns show multi-stage Docker builds, graceful shutdown handling, and concrete deployment commands. You get guidance on concurrency tuning (start at 80 for I/O bound, drop to 10 for memory-heavy), lazy loading heavy dependencies, and when to use VPC connectors (sparingly, they add latency). The Pub/Sub and Cloud Storage function examples are straightforward. It's Apache 2.0 licensed from vibeship-spawner-skills, so you can fork and adapt it. Good starting point if you're moving beyond the GCP quickstarts and want production patterns without the fluff.
$ npx -y skills add sickn33/antigravity-awesome-skills --skill gcp-cloud-run --agent claude-codeInstalls into .claude/skills of the current project.
Specialized skill for building production-ready serverless applications on GCP. Covers Cloud Run services (containerized), Cloud Run Functions (event-driven), cold start optimization, and event-driven architecture with Pub/Sub.
Examples are incomplete integration sketches: application helpers, IAM roles, queues, regions and health/startup probes must be supplied. Select an authorized project/service and budget, private ingress/auth by default, versioned Artifact Registry image and rollback revision. Historical nodejs20/GCR examples require supported-runtime and registry migration checks. Bound max instances and aggregate DB connections; minimum instances and boosts incur costs. A 2xx response must follow completed or durably enqueued work, with idempotency for retries. psutil host-memory readings may not reflect the container cgroup limit; use Cloud Monitoring/container metrics.
Read the detailed guide before executing this skill. It retains the complete procedure and reference material. Treat its safety, prerequisites, and validation requirements as mandatory. For focused work, load the relevant sections; for end-to-end work, read the guide completely.
# cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args:
- 'run'
- 'deploy'
- 'my-service'
- '--memory=1Gi' # Include /tmp overhead
- '--image=gcr.io/$PROJECT_ID/my-service'
import psutil
import logging
def log_memory():
memory = psutil.virtual_memory()
logging.info(f"Memory: {memory.percent}% used, "
f"{memory.available / 1024 / 1024:.0f}MB available")
Severity: HIGH
Situation: Setting concurrency to 1 for request isolation
Symptoms: Auto-scaling creates many container instances. High latency during traffic spikes. Increased cold starts. Higher costs from more instances.
Why this breaks: Setting concurrency to 1 means each container handles only one request at a time. During traffic spikes:
This should only be used when:
Recommended fix: Load-test a concurrency matching handler thread safety, peak memory, latency and downstream connection limits; concurrency 1 can be appropriate.
Use this skill when the request clearly matches the capabilities and patterns described above.
Sponsors