ARM Is a Stack Decision, Not a CPU Checkbox
An architecture view of ARM deployments, from workload fit and software support to platform choice, showing where performance, memory, storage, and operations shape the decision.
Loading…
Topic
Cloud
20 posts about Cloud. Every summary links to the original.
- 20 posts
- 10 companies
- 1 explainer
See the idea
Cloud explainers
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
How Cloud-Based Agent Sandboxing Works in Air
AI agents require sandboxing to restrict file, network, and system access, preventing unintended modifications and data leakage. The post categorizes five agent execution modes into local (workspace, git worktree) and remote (SSH, Docker, Cloud), with remote modes providing stronger isolation by default. In JetBrains Air, each cloud agent task runs in its own VM with the agent inside a Docker container, and all network connections are routed through a proxy that allows only trusted domains by default. Secrets are stored encrypted and exposed as environment variables, and the agent operates within the developer’s repository permissions. Cloud-based execution reduces local setup requirements and gives organizations control over network access policies, with cloud agents currently available to organizational users via Air in IDEs and Air Teams.
Modal crosses $1B in Annualized Run Rate and raises $750M Series D
Modal crossed $1B in annualized run rate and raised $750M in Series D funding at a $15.75B post-money valuation, led by Accel. Usage has tripled since the Series C five months ago, with year-over-year growth exceeding 15x, and the company now powers applications from companies including DoorDash, Cognition, and Runway. To avoid the friction of the old stack, Modal built its own file system, container runtime, scheduler, and networking from scratch on a capacity pool spanning over 20 clouds. Sandboxes, launched in 2023 for running LLM-generated code, now represent a $300M run rate product with nearly 3 billion sandboxes spun up and scaling to a million concurrent. New products include multi-node training with a single decorator giving a fully RDMA-connected cluster, Modal servers for HTTP serving, Endpoint Candidates for LLM serving, and generally available virtual machines.
Run less software - The Intercom Blog
To survive intense competition from copycats and dominant tech companies, software businesses must execute faster and more efficiently than their rivals. Run Less Software is a three-pillar philosophy that helps teams achieve this: choose standard, boring technologies to build deep expertise and reduce operational overhead; outsource undifferentiated heavy lifting like infrastructure to specialized third-party providers; and focus all engineering effort on creating enduring competitive advantage that directly serves customers. For example, Intercom consolidated from MongoDB and Postgres to AWS Aurora and DynamoDB, standardizing on MySQL and gaining 5x throughput at a 30% cost reduction with minimal custom code. By constraining the toolset, teams become expert operators who can make faster, cheaper decisions. The philosophy enables companies to manipulate time and stay ahead of competitors by systematically reducing the cost and risk of their engineering decisions.
Introducing Warm Agents, a TeamCity Plugin
The Warm Agents plugin for TeamCity reduces build queue time by maintaining a target number of idle, pre-started cloud agents, addressing the delay when builds wait for a starting agent. When idle agents drop below the target, TeamCity automatically provisions a new instance from the cloud image, ensuring builds start immediately; instances start in batches with short delays. The plugin works with any cloud provider TeamCity supports, requires TeamCity 2024.12.3 or later, and respects the cloud image’s hard limit on total running agents. Administrators configure warm agents via REST API calls, setting a target count per cloud image, and can schedule target changes using build triggers to scale down overnight and restore in the morning. The plugin trades cost for latency, as each idle agent consumes a build license and cloud instance cost, and exposes utilization and saturation metrics in Prometheus format.
Executable UDFs are now generally available on ClickHouse Cloud
Executable user-defined functions (UDFs) have moved from public beta to general availability on ClickHouse Cloud across AWS, GCP, and Azure. The GA release adds a Native runtime for precompiled statically linked binaries in Rust, Go, C++, and JavaScript, requiring both amd64 and arm64 architectures, alongside the existing Python support. UDFs now have network access to public endpoints, a per-process memory limit, a deterministic flag that enables query caching, and are not billed separately, running inside service pods. ClickHouse 26.6+ provides eight ProfileEvents counters and two asynchronous metrics for per-query UDF cost monitoring, and the Cloud API and Terraform provider support UDF management with per-service version pinning. The post demonstrates counting LLM tokens and grading completions using these UDFs, showing how to put tokenization libraries next to the data in ClickHouse.
What is a Cloud
A cloud-based database management system stores, manages, and queries data on third-party cloud infrastructure instead of local or on-premises servers. It retains capabilities such as query optimization, security, transactions, and support for relational SQL, NoSQL, data warehouse, and in-memory workloads, while operating across distributed nodes. Organizations can self-manage database software on cloud virtual machines or use DBaaS, where the provider manages the software and infrastructure; connections typically use SQL, APIs, or web consoles. Virtualized resources can scale, and providers may handle patching, backups, maintenance, and failover, while replication across availability zones supports recovery and availability. The comparison with on-premises systems covers ownership, scalability, cost models, maintenance, accessibility, control, compliance, total cost, and emerging capabilities including AI integration, vector search, autonomous operation, multicloud, hybrid, and serverless architectures.
Microsoft, NVIDIA, and Anthropic partnerships
Microsoft, NVIDIA, and Anthropic announced strategic partnerships to scale Anthropic’s Claude models on Microsoft Azure and broaden enterprise access to them. Anthropic committed to purchase $30 billion of Azure compute capacity and contract additional capacity up to one gigawatt, initially using NVIDIA Grace Blackwell and Vera Rubin systems. NVIDIA and Anthropic will collaborate on design and engineering to optimize Anthropic models for performance, efficiency, and total cost of ownership, while adapting future NVIDIA architectures to Anthropic workloads. Microsoft Foundry customers will be able to access Claude Sonnet 4.5, Claude Opus 4.1, and Claude Haiku 4.5, while Claude remains available across Microsoft’s Copilot products. Microsoft and NVIDIA committed up to $5 billion and $10 billion, respectively, to Anthropic; Amazon remains its primary cloud provider and training partner.
Announcing On-Demand Compute: Instant compute for your most intensive workloads
ClickHouse Cloud’s On-Demand Compute is announced in private preview as a way to run eligible queries on a shared pool of workers outside a service’s primary cluster, avoiding production contention and reactive autoscaling delays. It uses ClickHouse’s multistage distributed query execution and cost-based optimizer to distribute complex workloads, with queries requesting worker counts through settings including make_distributed_plan and distributed_plan_workers_num. Workers are leased for at least 60 seconds, reused during the lease, and released when it expires; concurrent queries share the pool, which grows to the largest request. In a stated benchmark, On-Demand Compute was faster for the tested workload and at 25 concurrent queries delivered similar performance while using 50% less compute, though results vary by query shape.
Cursor Projects
Cursor is launching Projects, a beta feature for taking on larger bodies of work such as features, migrations, and full applications. Each Project preserves context over months, runs on its own cloud computer through Cloud Agents, and coordinates parallel subagents rather than having the coordinator write code itself. Shared files synchronize across agents’ cloud and local machines, storing research, artifacts, codebase knowledge, and preferred working practices so later agents can use them. Projects can also subscribe to Slack channels, schedules, or pull requests and delegate work when signals arrive, while local agents handle testing that requires the user’s machine. Projects are accessible from Cursor’s left-hand navigation and are rolling out to all users in beta starting today.
Developing Enterprise Frontier Safeguards with our customers
Anthropic is announcing Enterprise Frontier Safeguards (EFS), designed to combine zero data retention (ZDR) with monitoring for serious misuse of frontier models. The service addresses enterprise concerns that detecting activity such as fraud, cyberattacks, or biological capability development, or stolen credentials, may require retaining and correlating traffic across sessions and accounts, while regulated organizations may not accept provider-held data or human review. EFS stores activity data in customer-controlled cloud infrastructure, under customer-managed encryption keys, access policies, and audit logging, while automated systems analyze a rolling traffic window and send flags directly to the customer for review. It will roll out in phases later this fall, support Anthropic and partner cloud offerings, and let customers opt into storage, encryption keys, and automated review without changing model behavior, pricing, or rate limits.
Self-hosted machines
Cursor’s self-hosted machines keep tool execution inside an organization’s own network, leaving the codebase, build outputs, and secrets on internal infrastructure while the agent handles tool calls locally. The feature supports My Machines for connecting one laptop or VM and team pools that provide named queues of workers, with capacity expanding as requests arrive and contracting when workers disconnect. Pools are repository-independent, can hibernate idle machines, and can restore them within a reconnect window, avoiding the need to keep costly capacity warm. Cloud agents can run on infrastructure including AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel, and E2B, while Linux and Mac workers add computer use for clicking, typing, screenshots, and browser control.
Cloud Agents Start 3x Faster with Builds
Cursor’s Cloud Agents now use Builds, ready-to-use copies of a development environment prepared in the background. These environments include cloned repositories, installed dependencies, and completed install commands, allowing agents to start without repeating setup each session. Cursor refreshes environments regularly, keeps warm copies, and activates only successful builds; internally, environments boot 10x faster and time to first token is 3x faster. If a commit or dependency update breaks a build, the last successful build remains active, while users receive a notification and can debug in the background. Builds can be inspected in the Cloud Agents dashboard, where logs, commit SHAs, statuses, and agent run associations are available, with tools for agents to inspect or manage them.
Together AI and Y Combinator partner to launch the first dedicated GPU cluster for the YC community
Together AI and Y Combinator are partnering to provide YC portfolio companies with a dedicated GPU cluster, addressing compute access as a growing bottleneck for AI-native startups. The service is designed for both inference and training, letting founders reserve, provision, and manage GPUs through Together’s self-service portal rather than making long-term commitments or routing usage through YC. Startups can run short-term sprints at long-term rates, use capacity from single-node workloads to larger deployments, and receive GPUs in minutes, while the cluster is already running at full utilization and companies can plan needs months ahead. Together says its research on attention mechanisms and the Mamba architecture targets faster inference and improved unit economics. The partners plan to expand the cluster and support startups as their requirements grow.
Cloud Environment Setup and Cloud Subagents in Agents Window
This release updates cloud agents in the Agents Window of the Cursor desktop app, adding cloud environment setup, cloud subagents, and more reliable movement between local and cloud sessions. Cursor can help configure a development environment in under 10 minutes while showing progress in a shared terminal, then capture the result as a reusable snapshot for faster startup and software testing by future agents. The /in-cloud command launches a subagent in its own virtual machine and branch, isolating long-running or parallel tasks while the local workspace remains responsive; /babysit lets a cloud agent iterate on a pull request remotely. Cloud subagents can run in the background, and sessions can be pulled back to a local computer for testing, with multiple cloud agents running in parallel.
Modernizing Artifact Storage at Uber
Uber’s legacy artifact platform used two five-node clusters with local disks, asynchronous replication, and GeoDNS failover to support builds across monorepos and microrepos. As artifact volume grew, limited node capacity, inconsistent replication, manual hardware evacuation, and risky multi-terabyte upgrades created operational and data-loss risks. Uber moved to a managed SaaS platform with multi-region availability, cross-region replication, and cloud-native blob storage, then added an internal validation proxy in front of it. The proxy uses MySQL metadata and conditional requests, including If-None-Match and If-Modified-Since, to validate artifacts against the SaaS origin while reusing unchanged bytes; failures can fall back to passthrough, preserving correctness at higher latency and egress cost. The design reduced operational risk, improved observability, and made artifact delivery more cost-efficient at scale.
Modal's Series C: Raising $355M at a $4.65B valuation
Modal announced a $355 million Series C at a $4.65 billion post-money valuation, led by General Catalyst and Redpoint, with participation from Menlo, Bain Capital Ventures, Accel, and all existing investors. The company grew fivefold since September and surpassed $300 million in annualized revenue. Modal is a cloud platform built for AI workloads, offering elastic inference, dynamic agent runtimes, and batch processing. Its Sandboxes feature, which provides isolated environments for untrusted code, has launched over 1 billion instances and accounts for more than a third of revenue. Modal plans to invest in low-latency inference, reinforcement learning infrastructure, and expanded agent computing capabilities.
Development environments for cloud agents
Cloud agents need a laptop-like development environment with cloned repositories, installed dependencies, credentials, and build-system access to complete engineering tasks end-to-end. This release adds configurable multi-repo environments, Dockerfile-based configuration, and tools that let Cursor set up and maintain those environments. Build secrets remain scoped to build steps, while improved layer caching makes cache-hit builds run 70% faster; Cursor also asks setup questions, flags missing credentials, validates configuration, and falls back to a base image with warnings when setup fails. Version histories, admin-controlled rollback, audit logs, and environment-scoped egress and secrets provide governance and isolation across environments for teams running parallelized agents.
The 5 Layers Every Cloud Commitment Depends On
Long-term hyperscale cloud commitments are presented as distributed-systems problems with expensive consequences when physical assumptions are wrong. The post proposes a dependency sequence across regional and availability-zone topology, power architecture, fit-for-purpose compute, SKU qualification, and network design. It compares application-observable latency with bare-metal RTT, uses power consumption as a migration check, and argues that workload characteristics should drive memory-to-core ratios, silicon generations, instance families, and routing choices rather than provider defaults. It also explains why zone placement, inter-zone and inter-region transfer, and egress pricing affect quorum latency, reliability, and economics, while noting that cross-region traffic may require explicit justification. The conclusion is that these constraints compound over the commitment unless teams manage architectural drift, with software and contracting layers addressed separately.
Shopify’s Infrastructure Collaboration with Google
Shopify announces that it is building its Cloud with Google after more than a decade of operating the foundation of its commerce cloud through its own data centers and incremental public-cloud adoption. Its infrastructure evolved from database and application sharding, performance testing, automated failovers, and Docker-based immutable infrastructure toward Kubernetes orchestration, after the company initially built minimal container-management features itself. During the migration, Shopify created Shop Mover, a selective database migration tool that rebalances shops between shards with an average of 2.5s downtime per shop, and moved more than 50% of data-center workloads to Google Cloud. It also grew to more than 400 production services, consolidated them on Kubernetes through a platform-as-a-service, and contributed to and used Grafeas for software supply-chain auditing and governance.
Future Proofing Our Cloud Storage Usage
Shopify’s growth from 375,000 to over 600,000 merchants coincided with about 450,000 S3 operations per second and rising error rates plus read and write latency. Merchant-uploaded images and theme installations exposed a partitioning problem: S3 groups keys by shortest common asset prefixes, and abrupt throughput spikes could trigger SlowDown failures across a range of shops. Black-box observations suggested affected keyspaces were unlikely to recur, while newer shops were more often involved, though the latter was explicitly described as a shaky inference. Shopify prepended a hash-generated digest to new shops’ asset keys, distributing writes across more partitions instead of concentrating them under shop-specific prefixes. After the first post-change SlowDown event, exceptions nearly disappeared, while median latency for digested assets fell about 60% and the 95th percentile about 25%.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.