Archive
Benchmarking reCAPTCHA v3 Solver Services: Speed vs Quality Analysis

When implementing automated systems that need to solve reCAPTCHA v3 challenges, choosing the right solver service can significantly impact both your success rate and operational costs. We conducted a comprehensive benchmark test of five popular reCAPTCHA v3 solving services to compare their performance in terms of both speed and quality scores.
The Results
We tested five major captcha solving services: CapSolver, 2Captcha, AntiCaptcha, NextCaptcha, and DeathByCaptcha. Each service was evaluated both with and without residential proxy support (using Decodo residential proxies).
Speed Performance Rankings
Fastest to Slowest (without proxy):
- CapSolver – 3,383ms (3.4 seconds)
- NextCaptcha – 6,725ms (6.7 seconds)
- DeathByCaptcha – 16,212ms (16.2 seconds)
- AntiCaptcha – 17,069ms (17.1 seconds)
- 2Captcha – 36,149ms (36.1 seconds)
With residential proxy:
- CapSolver – 5,101ms (5.1 seconds)
- NextCaptcha – 10,875ms (10.9 seconds)
- DeathByCaptcha – 10,861ms (10.9 seconds)
- 2Captcha – 25,749ms (25.7 seconds)
- AntiCaptcha – Failed (task type not supported with proxy)
Quality Score Results
Here’s where the results become particularly interesting: all services that successfully completed the challenge returned identical scores of 0.10. This uniformly low score across all providers suggests we’re observing a fundamental characteristic of how these services interact with Google’s reCAPTCHA v3 system rather than differences in solver quality.
What Do These Results Tell Us?
1. The Score Mystery
A reCAPTCHA v3 score of 0.10 is at the very bottom of Google’s scoring range (0.0-1.0), indicating that Google’s system detected these tokens as very likely originating from bots. This consistent result across all five services reveals several important insights:
Why such low scores?
- reCAPTCHA v3 uses machine learning trained on actual site traffic patterns
- Without established traffic history, the system defaults to suspicious scores
- Commercial solver services are inherently detectable by Google’s sophisticated fingerprinting
- The test environment may lack the organic traffic patterns needed for v3 to generate higher scores
As mentioned in our research, CleanTalk found that reCAPTCHA v3 often returns consistent scores in test environments without production traffic. The system needs time to “learn” what normal traffic looks like for a given site before it can effectively differentiate between humans and bots.
2. Speed is the Real Differentiator
Since all services returned the same quality score, speed becomes the primary differentiator:
CapSolver emerged as the clear winner, solving challenges in just 3.4 seconds without proxy and 5.1 seconds with proxy. This represents a 10x speed advantage over the slowest service (2Captcha at 36 seconds).
NextCaptcha came in second place with respectable times of 6.7 seconds (no proxy) and 10.9 seconds (with proxy), making it a solid middle-ground option.
DeathByCaptcha and AntiCaptcha performed similarly at around 16-17 seconds without proxy, though AntiCaptcha failed to support proxy-based solving for this captcha type.
2Captcha was significantly slower at 36 seconds without proxy, though it did improve to 25.7 seconds with proxy enabled.
3. Proxy Support Variations
Proxy support proved inconsistent across services:
- Most services handled proxies well, with CapSolver, NextCaptcha, DeathByCaptcha, and 2Captcha all successfully completing challenges through residential proxies
- AntiCaptcha failed with proxy, returning an “ERROR_TASK_NOT_SUPPORTED” error, suggesting their proxy-based reCAPTCHA v3 implementation may have limitations
- Proxy impact on speed varied: Some services (2Captcha) were faster with proxy, while others (CapSolver, NextCaptcha) were slower
4. Success Rates
All services except AntiCaptcha (with proxy) achieved 100% success rates, meaning they reliably returned valid tokens. However, the validity of a token doesn’t correlate with its quality score—all tokens were valid but all received low scores from Google.
Practical Implications
For High-Volume Operations
If you’re processing thousands of captchas daily, CapSolver’s 3-5 second solve time provides a massive throughput advantage. At scale, this speed difference translates to:
- Processing 1,000 captchas with CapSolver: ~56 minutes
- Processing 1,000 captchas with 2Captcha: ~10 hours
For Quality-Sensitive Applications
The uniform 0.10 scores reveal a hard truth: commercial reCAPTCHA v3 solvers may not produce high-quality tokens that pass strict score thresholds. If your target site requires scores above 0.5 or 0.7, these services may not be suitable regardless of which one you choose.
Cost Considerations
Since all services returned the same quality, cost-per-solve becomes the tiebreaker alongside speed:
- CapSolver: ~$1.00 per 1,000 solves
- 2Captcha: ~$2.99 per 1,000 solves
- AntiCaptcha: ~$2.00 per 1,000 solves
CapSolver offers the best speed-to-cost ratio in this comparison.
The Bigger Picture: reCAPTCHA v3 Limitations
These results illuminate a broader challenge with reCAPTCHA v3 solver services. Google’s v3 system is fundamentally different from v2:
- v2 presented challenges that could be solved by humans or AI
- v3 analyzes behavior patterns, browser fingerprints, and site-specific traffic history
Commercial solvers can generate valid tokens, but those tokens carry telltale signatures that Google’s machine learning readily identifies. The consistently low scores suggest that Google has effective detection mechanisms for solver-generated traffic.
When Might Scores Improve?
Based on research and documentation:
- Production environments with real organic traffic may see better scores
- Time – letting reCAPTCHA v3 “train” on a site for days or weeks
- Mixed traffic – solver tokens mixed with legitimate user traffic
- Residential proxies – though our test showed this alone doesn’t improve scores
Conclusions and Recommendations
If Speed Matters Most
Choose CapSolver. Its 3-5 second solve times are unmatched, and at $1 per 1,000 solves, it’s also the most cost-effective option.
If You Need Proxy Support
Avoid AntiCaptcha for proxy-based v3 solving. CapSolver, NextCaptcha, and DeathByCaptcha all handled residential proxies successfully.
If Quality Scores Matter
Reconsider using solver services entirely. The uniform 0.10 scores suggest that commercial solvers may not be suitable for sites with strict score requirements. Consider alternative approaches:
- Browser automation with real user simulation
- Residential proxy networks with actual human solvers
- Challenging whether reCAPTCHA v3 is the right solution for your use case
The Bottom Line
For raw performance in a test environment, CapSolver dominated with the fastest solve times and lowest cost. However, the universal 0.10 quality scores across all services reveal that speed and cost may be moot points if your application requires high-quality scores that pass Google’s bot detection.
The real takeaway? reCAPTCHA v3 is doing its job—it successfully identifies solver-generated tokens regardless of which service you use. If you need high scores, you’ll need more sophisticated approaches than simply purchasing tokens from commercial solving services.
This benchmark was conducted in January 2026 using production API credentials for all services. Tests were performed with both direct connections and residential proxy infrastructure. Individual results may vary based on site configuration, traffic patterns, and Google’s evolving detection systems.
Migrating Google Cloud Run to Scaleway: Bringing Your Cloud Infrastructure Back to Europe
Introduction: Why European Cloud Sovereignty Matters Now More Than Ever

In an era of increasing geopolitical tensions, data sovereignty concerns, and evolving international relations, European companies are reconsidering their dependence on US-based cloud providers. The EU’s growing emphasis on digital sovereignty, combined with uncertainties around US data access laws like the CLOUD Act and recent political developments, has made many businesses uncomfortable with storing sensitive data on American infrastructure.
For EU-based companies running containerized workloads on Google Cloud Run, there’s good news: migrating to European alternatives like Scaleway is surprisingly straightforward. This guide will walk you through the technical process of moving your Cloud Run services to Scaleway’s Serverless Containers—keeping your applications running while bringing your infrastructure back under European jurisdiction.
Why Scaleway?
Scaleway, a French cloud provider founded in 1999, offers a compelling alternative to Google Cloud Run:
- 🇪🇺 100% European: All data centers located in France, Netherlands, and Poland
- 📜 GDPR Native: Built from the ground up with European data protection in mind
- 💰 Transparent Pricing: No hidden costs, generous free tiers, and competitive rates
- 🔒 Data Sovereignty: Your data never leaves EU jurisdiction
- ⚡ Scale-to-Zero: Just like Cloud Run, pay only for actual usage
- 🌱 Environmental Leadership: Strong commitment to sustainable cloud infrastructure
Most importantly: Scaleway Serverless Containers are technically equivalent to Google Cloud Run. Both are built on Knative, meaning your containers will run identically on both platforms.
Prerequisites
Before starting, ensure you have:
- An existing Google Cloud Run service
- Windows machine with PowerShell
gcloudCLI installed and authenticated- A Scaleway account (free to create)
- Skopeo installed (we’ll cover this)
Understanding the Architecture
Both Google Cloud Run and Scaleway Serverless Containers work the same way:
- You provide a container image
- The platform runs it on-demand via HTTPS endpoints
- It scales automatically (including to zero when idle)
- You pay only for execution time
The migration process is simply:
- Copy your container image from Google’s registry to Scaleway’s registry
- Deploy it as a Scaleway Serverless Container
- Update your DNS/endpoints
No code changes required—your existing .NET, Node.js, Python, Go, or any other containerized application works as-is.
Step 1: Install Skopeo (Lightweight Docker Alternative)
Since we’re on Windows and don’t want to run full Docker Desktop, we’ll use Skopeo—a lightweight tool designed specifically for copying container images between registries.
Install via winget:
powershell
winget install RedHat.Skopeo
Or download directly from: https://github.com/containers/skopeo/releases
Why Skopeo?
- No daemon required: No background services consuming resources
- Direct registry-to-registry transfer: Images never touch your local disk
- Minimal footprint: ~50MB vs. several GB for Docker Desktop
- Perfect for CI/CD: Designed for automation and registry operations
Configure Skopeo’s Trust Policy
Skopeo requires a policy file to determine which registries to trust. Create it:
powershell
# Create the config directoryNew-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.config\containers"# Create a permissive policy that trusts all registries@"{ "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "docker-daemon": { "": [{"type": "insecureAcceptAnything"}] } }}"@ | Out-File -FilePath "$env:USERPROFILE\.config\containers\policy.json" -Encoding utf8
For production environments, you might want a more restrictive policy that only trusts specific registries:
powershell
@"{ "default": [{"type": "reject"}], "transports": { "docker": { "gcr.io": [{"type": "insecureAcceptAnything"}], "europe-west2-docker.pkg.dev": [{"type": "insecureAcceptAnything"}], "rg.fr-par.scw.cloud": [{"type": "insecureAcceptAnything"}] } }}"@ | Out-File -FilePath "$env:USERPROFILE\.config\containers\policy.json" -Encoding utf8
Step 2: Find Your Cloud Run Container Image
Your Cloud Run service uses a specific container image. To find it:
Via gcloud CLI (recommended):
bash
gcloud run services describe YOUR-SERVICE-NAME \ --region=YOUR-REGION \ --project=YOUR-PROJECT \ --format='value(spec.template.spec.containers[0].image)'```This returns the full image URL, something like:```europe-west2-docker.pkg.dev/your-project/cloud-run-source-deploy/your-service@sha256:abc123...
Via Google Cloud Console:
- Navigate to Cloud Run in the console
- Click your service
- Go to the “Revisions” tab
- Look for “Container image URL”
The @sha256:... digest is important—it ensures you’re copying the exact image currently running in production.
Step 3: Set Up Scaleway Container Registry
Create a Scaleway Account
- Sign up at https://console.scaleway.com/
- Complete email verification
- Navigate to the console
Create a Container Registry Namespace
- Go to Containers → Container Registry
- Click Create namespace
- Choose a region (Paris, Amsterdam, or Warsaw)
- Important: Choose the same region where you’ll deploy your containers
- Enter a namespace name (e.g.,
my-containers,production)- Must be unique within that region
- Lowercase, numbers, and hyphens only
- Set Privacy to Private
- Click Create
Your registry URL will be: rg.fr-par.scw.cloud/your-namespace
Create API Credentials
- Click your profile → API Keys (or visit https://console.scaleway.com/iam/api-keys)
- Click Generate API Key
- Give it a name (e.g., “container-migration”)
- Save the Secret Key securely—it’s only shown once
- Note both the Access Key and Secret Key
Step 4: Copy Your Container Image
Now comes the magic—copying your container directly from Google to Scaleway without downloading it locally.
Authenticate and Copy:
powershell
# Set your Scaleway secret key as environment variable (more secure)$env:SCW_SECRET_KEY = "your-scaleway-secret-key-here"# Copy the image directly between registriesskopeo copy ` --src-creds="oauth2accesstoken:$(gcloud auth print-access-token)" ` --dest-creds="nologin:$env:SCW_SECRET_KEY" ` docker://europe-west2-docker.pkg.dev/your-project/cloud-run-source-deploy/your-service@sha256:abc123... ` docker://rg.fr-par.scw.cloud/your-namespace/your-service:latest```### What's Happening:- `--src-creds`: Authenticates with Google using your gcloud session- `--dest-creds`: Authenticates with Scaleway using your API key- Source URL: Your Google Artifact Registry image- Destination URL: Your Scaleway Container RegistryThe transfer happens directly between registries—your Windows machine just orchestrates it. Even a multi-GB container copies in minutes.### Verify the Copy:1. Go to https://console.scaleway.com/registry/namespaces2. Click your namespace3. You should see your service image listed with the `latest` tag## Step 5: Deploy to Scaleway Serverless Containers### Create a Serverless Container Namespace:1. Navigate to **Containers** → **Serverless Containers**2. Click **Create namespace**3. Choose the **same region** as your Container Registry4. Give it a name (e.g., `production-services`)5. Click **Create**### Deploy Your Container:1. Click **Create container**2. **Image source**: Select "Scaleway Container Registry"3. Choose your namespace and image4. **Configuration**: - **Port**: Set to the port your app listens on (usually 8080 for Cloud Run apps) - **Environment variables**: Copy any env vars from Cloud Run - **Resources**: - Memory: Start with what you used in Cloud Run - vCPU: 0.5-1 vCPU is typical - **Scaling**: - **Min scale**: `0` (enables scale-to-zero, just like Cloud Run) - **Max scale**: Set based on expected traffic (e.g., 10)5. Click **Deploy container**### Get Your Endpoint:After deployment (1-2 minutes), you'll receive an HTTPS endpoint:```https://your-container-namespace-xxxxx.functions.fnc.fr-par.scw.cloud
This is your public API endpoint—no API Gateway needed, SSL included for free.
Step 6: Test Your Service
powershell
# Test the endpointInvoke-WebRequest -Uri "https://your-container-url.functions.fnc.fr-par.scw.cloud/your-endpoint"
Your application should respond identically to how it did on Cloud Run.
Understanding the Cost Comparison
Google Cloud Run Pricing (Typical):
- vCPU: $0.00002400/vCPU-second
- Memory: $0.00000250/GB-second
- Requests: $0.40 per million
- Plus: API Gateway, Load Balancer, or other routing costs
Scaleway Serverless Containers:
- vCPU: €0.00001/vCPU-second (€1.00 per 100k vCPU-s)
- Memory: €0.000001/GB-second (€0.10 per 100k GB-s)
- Requests: Free (no per-request charges)
- HTTPS endpoint: Free (included)
- Free Tier: 200k vCPU-seconds + 400k GB-seconds per month
Example Calculation:
For an API handling 1 million requests/month, 200ms average response time, 1 vCPU, 2GB memory:
Google Cloud Run:
- vCPU: 1M × 0.2s × $0.000024 = $4.80
- Memory: 1M × 0.2s × 2GB × $0.0000025 = $1.00
- Requests: 1M × $0.0000004 = $0.40
- Total: ~$6.20/month
Scaleway:
- vCPU: 200k vCPU-s → Free (within free tier)
- Memory: 400k GB-s → Free (within free tier)
- Total: €0.00/month
Even beyond free tiers, Scaleway is typically 30-50% cheaper, with no surprise charges.
Key Differences to Be Aware Of
Similarities (Good News):
✅ Both use Knative under the hood ✅ Both support HTTP, HTTP/2, WebSocket, gRPC ✅ Both scale to zero automatically ✅ Both provide HTTPS endpoints ✅ Both support custom domains ✅ Both integrate with monitoring/logging
Differences:
- Cold start: Scaleway takes ~2-5 seconds (similar to Cloud Run)
- Idle timeout: Scaleway scales to zero after 15 minutes (vs. Cloud Run’s varies)
- Regions: Limited to EU (Paris, Amsterdam, Warsaw) vs. Google’s global presence
- Ecosystem: Smaller ecosystem than GCP (but rapidly growing)
When Scaleway Makes Sense:
- ✅ Your primary users/customers are in Europe
- ✅ GDPR compliance is critical
- ✅ You want to avoid US jurisdiction over your data
- ✅ You prefer transparent, predictable pricing
- ✅ You don’t need GCP-specific services (BigQuery, etc.)
When to Consider Carefully:
- ⚠️ You need global edge distribution (though you can use CDN)
- ⚠️ You’re heavily integrated with other GCP services
- ⚠️ You need GCP’s machine learning services
- ⚠️ Your customers are primarily in Asia/Americas
Additional Migration Considerations
Environment Variables and Secrets:
Scaleway offers Secret Manager integration. Copy your Cloud Run secrets:
- Go to Secret Manager in Scaleway
- Create secrets matching your Cloud Run environment variables
- Reference them in your container configuration
Custom Domains:
Both platforms support custom domains. In Scaleway:
- Go to your container settings
- Add custom domain
- Update your DNS CNAME to point to Scaleway’s endpoint
- SSL is handled automatically
Databases and Storage:
If you’re using Cloud SQL or Cloud Storage:
- Databases: Consider Scaleway’s Managed PostgreSQL/MySQL or Serverless SQL Database
- Object Storage: Scaleway Object Storage is S3-compatible
- Or: Keep using GCP services (cross-cloud is possible, but adds latency)
Monitoring and Logging:
Scaleway provides Cockpit (based on Grafana):
- Automatic logging for all Serverless Containers
- Pre-built dashboards
- Integration with alerts and metrics
- Similar to Cloud Logging/Monitoring
The Broader Picture: European Digital Sovereignty
This migration isn’t just about cost savings or technical features—it’s about control.
Why EU Companies Are Moving:
- Legal Protection: GDPR protections are stronger when data never leaves EU jurisdiction
- Political Risk: Reduces exposure to US government data requests under CLOUD Act
- Supply Chain Resilience: Diversification away from Big Tech dependency
- Supporting European Tech: Strengthens the European cloud ecosystem
- Future-Proofing: As digital sovereignty regulations increase, early movers are better positioned
The Economic Argument:
Every euro spent with European cloud providers:
- Stays in the European economy
- Supports European jobs and innovation
- Builds alternatives to US/Chinese tech dominance
- Strengthens Europe’s strategic autonomy
Conclusion: A Straightforward Path to Sovereignty
Migrating from Google Cloud Run to Scaleway Serverless Containers is technically simple—often taking just a few hours for a typical service. The containers are identical, the pricing is competitive, and the operational model is the same.
But beyond the technical benefits, there’s a strategic argument: as a European company, every infrastructure decision is a choice about where your data lives, who has access to it, and which ecosystem you’re supporting.
Scaleway (and other European cloud providers) aren’t perfect replacements for every GCP use case. But for containerized APIs and web services—which represent the majority of Cloud Run workloads—they’re absolutely production-ready alternatives that keep your infrastructure firmly within European jurisdiction.
In 2026’s geopolitical landscape, that’s not just a nice-to-have—it’s increasingly essential.
Resources
- Scaleway Serverless Containers: https://www.scaleway.com/en/serverless-containers/
- Scaleway Documentation: https://www.scaleway.com/en/docs/
- Skopeo Documentation: https://github.com/containers/skopeo
- European Cloud Providers: Research Scaleway, OVHcloud, Hetzner, and others
- EU Digital Sovereignty: European Commission digital strategy resources
Have you migrated your infrastructure back to Europe? Share your experience in the comments below.
Google Calendar Privacy Proxy
https://github.com/infiniteloopltd/Google-Calendar-Redactor-Proxy/
A lightweight Google Cloud Run service that creates privacy-protected calendar feeds from Google Calendar. Share your availability with colleagues without exposing personal appointment details.
The Problem
You want to share your calendar availability with work colleagues, but:
- You have multiple calendars (work, personal, family) that you need to consolidate
- Google Calendar’s subscribed calendars (ICS feeds) don’t count toward your Outlook free/busy status
- You don’t want to expose personal appointment details to work contacts
- Outlook’s native calendar sharing only works with Exchange/Microsoft 365 calendars, not external ICS subscriptions
This service solves that problem by creating a privacy-filtered calendar feed that Outlook can subscribe to, showing you as “Busy” during your appointments without revealing what those appointments are.
How It Works
Google Calendar → This Service → Privacy-Protected ICS Feed → Outlook
(full details) (redaction) (busy blocks only) (subscription)
The service:
- Fetches your Google Calendar ICS feed using the private URL
- Strips out all identifying information (titles, descriptions, locations, attendees)
- Replaces event summaries with “Busy”
- Preserves all timing information (when you’re busy/free)
- Returns a sanitized ICS feed that Outlook can subscribe to
Use Cases
- Multiple calendar consolidation: Combine work, personal, and family calendars into one availability view
- Privacy-protected sharing: Share when you’re busy without sharing what you’re doing
- Cross-platform calendaring: Bridge Google Calendar into Outlook environments
- Professional boundaries: Keep personal life private while showing accurate availability
Quick Start
1. Get Your Google Calendar Private URL
- Open Google Calendar
- Click the ⚙️ Settings icon → Settings
- Select your calendar from the left sidebar
- Scroll to “Integrate calendar”
- Copy the “Secret address in iCal format” URL
Your URL will look like:
https://calendar.google.com/calendar/ical/info%40infiniteloop.ie/private-xxxxxxx/basic.ics
2. Deploy the Service
# Edit deploy.bat and set your PROJECT_ID deploy.bat # Or deploy manually gcloud run deploy calendar-proxy --source . --platform managed --region europe-west1 --allow-unauthenticated
You’ll get a service URL like: https://calendar-proxy-xxxxxxxxxx-ew.a.run.app
3. Construct Your Privacy-Protected Feed URL
From your Google Calendar URL:
https://calendar.google.com/calendar/ical/info%xxxxx.xxx/private-xxxxxxx/basic.ics
Extract:
- calendarId:
info@infiniteloop.ie(URL decoded) - privateKey:
xxxxxxxxxx(just the key, without “private-” prefix)
Build your proxy URL:
https://calendar-proxy-xxxxxxxxxx-ew.a.run.app/calendar?calendarId=info@infiniteloop.ie&privateKey=xxxxxxx
4. Subscribe in Outlook
Outlook Desktop / Web
- Open Outlook
- Go to Calendar
- Click Add Calendar → Subscribe from web
- Paste your proxy URL
- Give it a name (e.g., “My Availability”)
- Click Import
Outlook will now show:
- ✅ Blocked time during your appointments
- ✅ “Busy” status for those times
- ❌ No details about what the appointments are
What Gets Redacted
The service removes all identifying information:
| Original ICS Property | Result |
|---|---|
SUMMARY: (event title) | → "Busy" |
DESCRIPTION: (event details) | → Removed |
LOCATION: (where) | → Removed |
ORGANIZER: (who created it) | → Removed |
ATTENDEE: (participants) | → Removed |
URL: (meeting links) | → Removed |
ATTACH: (attachments) | → Removed |
CLASS: (privacy) | → Set to PRIVATE |
What Gets Preserved
All timing and scheduling information remains intact:
- ✅ Event start times (
DTSTART) - ✅ Event end times (
DTEND) - ✅ Event duration
- ✅ Recurring events (
RRULE) - ✅ Exception dates (
EXDATE) - ✅ Event status (confirmed, tentative, cancelled)
- ✅ Time zones
- ✅ All-day events
- ✅ Unique identifiers (
UID)
Technical Details
Stack: .NET 8 / ASP.NET Core Minimal API
Hosting: Google Cloud Run (serverless)
Cost: Virtually free for personal use (Cloud Run free tier: 2M requests/month)
Latency: ~200-500ms per request (fetches from Google, processes, returns)
API Endpoint
GET /calendar?calendarId={id}&privateKey={key}
Parameters:
calendarId(required): Your Google Calendar ID (usually your email)privateKey(required): The private key from your Google Calendar ICS URL
Response:
- Content-Type:
text/calendar; charset=utf-8 - Body: Privacy-redacted ICS feed
Local Development
# Run locally dotnet run # Test curl "http://localhost:8080/calendar?calendarId=test@example.com&privateKey=abc123"
Deployment
Prerequisites
- Google Cloud SDK installed
- .NET 8 SDK installed
- GCP project with Cloud Run API enabled
- Billing enabled on your GCP project
Deploy
# Option 1: Use the batch file deploy.bat # Option 2: Manual deployment gcloud run deploy calendar-proxy ^ --source . ^ --platform managed ^ --region europe-west1 ^ --allow-unauthenticated ^ --memory 512Mi
The --allow-unauthenticated flag is required so that Outlook can fetch your calendar without authentication. Your calendar data is still protected by the private key in the URL.
Security & Privacy
Is This Secure?
Yes, with caveats:
✅ Your calendar data is already protected by Google’s private key mechanism
✅ No data is stored – the service is stateless and doesn’t log calendar contents
✅ HTTPS encrypted – All traffic is encrypted in transit
✅ Minimal attack surface – Simple pass-through service with redaction
⚠️ Considerations:
- Your private key is in the URL you share (same as Google’s original ICS URL)
- Anyone with your proxy URL can see your busy/free times (but not details)
- The service runs as
--allow-unauthenticatedso Outlook can fetch it - If you need stricter access control, consider adding authentication
Privacy Features
- Strips all personally identifying information
- Marks all events as
CLASS:PRIVATE - No logging of calendar contents
- No data persistence
- Stateless operation
Recommendations
- Don’t share your proxy URL publicly
- Treat it like a password – it grants access to your availability
- Regenerate your Google Calendar private key if compromised
- Monitor your Cloud Run logs for unexpected access patterns
Cost Estimation
Google Cloud Run pricing (as of 2025):
- Free tier: 2M requests/month, 360,000 GB-seconds/month
- Typical calendar: Refreshes every 30-60 minutes
- Monthly cost: $0 for personal use (well within free tier)
Even with 10 people subscribing to your calendar refreshing every 30 minutes:
- ~14,400 requests/month
- ~$0.00 cost
Troubleshooting
“404 Not Found” when subscribing in Outlook
- Verify your service is deployed:
gcloud run services list - Check your URL is correctly formatted
- Ensure
--allow-unauthenticatedis set
“Invalid calendar” error
- Verify your Google Calendar private key is correct
- Test the URL directly in a browser first
- Check that your calendarId doesn’t have URL encoding issues
Events not showing up
- Google Calendar ICS feeds can take 12-24 hours to reflect changes
- Try re-subscribing to the calendar in Outlook
- Verify the original Google Calendar ICS URL works
Deployment fails
# Ensure you're authenticated gcloud auth login # Set your project gcloud config set project YOUR_PROJECT_ID # Enable required APIs gcloud services enable run.googleapis.com gcloud services enable cloudbuild.googleapis.com
Limitations
- Refresh rate: Calendar clients typically refresh ICS feeds every 30-60 minutes (not real-time)
- Google’s ICS feed: Updates can take up to 24 hours to reflect in the ICS feed
- Authentication: No built-in authentication (relies on URL secrecy)
- Multi-calendar: Requires one proxy URL per Google Calendar
Alternatives Considered
| Solution | Pros | Cons |
|---|---|---|
| Native Outlook calendar sharing | Built-in, real-time | Only works with Exchange calendars |
| Calendly/Bookings | Professional, feature-rich | Monthly cost, overkill for simple availability |
| Manual sync (Zapier/Power Automate) | Works | Complex setup, ongoing maintenance |
| This solution | Simple, free, privacy-focused | Relies on ICS feed delays |
Contributing
Contributions welcome! Areas for enhancement:
- Add basic authentication support
- Support multiple calendars in one feed
- Caching layer to reduce Google Calendar API calls
- Health check endpoint
- Metrics/monitoring
- Custom “Busy” text per calendar
License
MIT License – free to use, modify, and distribute.
Author
Created by Infinite Loop Development Ltd to solve a real business need for calendar privacy across platforms. https://github.com/infiniteloopltd/Google-Calendar-Redactor-Proxy/