GCP Supported Services
NightOps supports automated start/stop management for the following Google Cloud Platform services. These services can be safely turned off and restored without requiring manual reconfiguration.
Supported Services Overview
| Service | Stop Method | Start Method | Data Preserved | Config Preserved |
|---|---|---|---|---|
| Compute Engine | Stop Instance | Start Instance | ✅ | ✅ |
| Cloud SQL | Stop Instance | Start Instance | ✅ | ✅ |
| Cloud Run | Scale to 0 | Restore Instances | N/A | ✅ |
| GKE Node Pools | Scale to 0 | Restore Size | ✅ (with PD) | ✅ |
Compute Engine
Compute Engine VM instances can be stopped and started without losing configuration or persistent disk data.
API Operations
| Operation | API Call | Description |
|---|---|---|
| List | instances.list | List all instances in a zone |
| Stop | instances.stop | Stop a running instance |
| Start | instances.start | Start a stopped instance |
| Status | instances.get | Check instance status |
What's Preserved
- ✅ Persistent disks and data
- ✅ Network configuration
- ✅ Service account
- ✅ Internal IP address
- ✅ Metadata and labels
- ✅ Machine type configuration
Caveats
Ephemeral external IPs change on restart. Use static external IPs if a fixed IP is required.
Local SSD data is lost when an instance stops. Only persistent disk data is retained.
Preemptible and Spot VMs cannot be stopped, only deleted and recreated.
Cloud SQL
Cloud SQL database instances can be stopped and started, preserving all data and configuration.
API Operations
| Operation | API Call | Description |
|---|---|---|
| List | instances.list | List all Cloud SQL instances |
| Stop | instances.patch (activationPolicy: NEVER) | Stop a database instance |
| Start | instances.patch (activationPolicy: ALWAYS) | Start a database instance |
| Status | instances.get | Check instance status |
What's Preserved
- ✅ All data
- ✅ Database configuration
- ✅ Connection name
- ✅ Private IP configuration
- ✅ Automated backups configuration
- ✅ Maintenance windows
Caveats
Cloud SQL uses activationPolicy to control instance state. Setting to NEVER stops the instance, ALWAYS starts it.
Stopping a High Availability instance also stops the standby. Both resume together.
Read replicas must be stopped separately from their primary instance.
Cloud Run
Cloud Run services can be scaled to zero instances and restored to their previous configuration.
API Operations
| Operation | API Call | Description |
|---|---|---|
| List | services.list | List all Cloud Run services |
| Stop | services.patch (minInstances: 0, maxInstances: 0) | Scale to zero |
| Start | services.patch (restore min/max) | Restore instance count |
| Status | services.get | Check service status |
What's Preserved
- ✅ Container configuration
- ✅ Environment variables
- ✅ Service account
- ✅ VPC connector
- ✅ Domain mappings
- ✅ Traffic configuration
Caveats
When scaled to zero, the first request after restoration will experience a cold start delay.
NightOps stores the original minInstances value before scaling to zero for accurate restoration.
GKE Node Pools
GKE managed node pools can be scaled to zero nodes while preserving cluster configuration.
API Operations
| Operation | API Call | Description |
|---|---|---|
| List | projects.locations.clusters.nodePools.list | List all node pools |
| Stop | projects.locations.clusters.nodePools.setSize (nodeCount: 0) | Scale to zero |
| Start | projects.locations.clusters.nodePools.setSize (restore) | Restore node count |
| Status | projects.locations.clusters.nodePools.get | Check node pool status |
What's Preserved
- ✅ Node pool configuration
- ✅ Node image and machine type
- ✅ Service account
- ✅ Network tags
- ✅ Kubernetes labels and taints
- ✅ Autoscaling configuration
Caveats
The GKE control plane (Autopilot or Standard) still incurs cost even with zero nodes.
Stateful workloads need PersistentVolumeClaims backed by Persistent Disks to retain data.
Scale-up takes 2-5 minutes for nodes to become ready and pods to be scheduled.
Unsupported Services
The following services cannot be safely automated without manual intervention:
| Service | Reason |
|---|---|
| Memorystore | No stop functionality; delete loses data |
| Cloud Spanner | No stop; scaling to 0 nodes not allowed |
| Dataflow | Jobs must complete or be cancelled |
| Cloud Composer | Environment stop requires full recreation |
| Filestore | No stop functionality; delete loses data |
Resource Labeling
For NightOps to manage resources, apply these labels:
nightops-managed: true
nightops-schedule: <schedule-id>
nightops-environment: staging | development | testing
Label-Based Filtering Example
// List only NightOps-managed Compute instances
const instances = await computeService.list({
managedOnly: true,
scheduleId: "schedule-123"
});
Multi-Project Support
NightOps supports managing resources across multiple GCP projects using service account impersonation.
Architecture
┌─────────────────┐ ┌─────────────────┐
│ Hub Project │ │ Spoke Project │
│ (NightOps) │────────▶│ (Customer) │
│ │ Impersonate│ │
└─────────────────┘ └─────────────────┘
Setup Requirements
- Create a service account in each spoke project
- Grant the NightOps service account permission to impersonate
- Assign required IAM roles (see GCP IAM Policy Reference)
// Cross-project access
const compute = new ComputeService({
projectId: "spoke-project-id",
impersonateServiceAccount: "nightops@spoke-project.iam.gserviceaccount.com"
});
Next Steps
- GCP IAM Policy Reference - Required permissions for NightOps