DigitalOcean исторически выбрала самую простую модель: виртуальная машина за фиксированную цену, предсказуемый прайс и понятная панель. Для стартапа это часто идеальный первый дом: прототип поднимается за вечер, счёт не содержит сюрпризов, а когда проект вырастает, компания до последнего держится на droplets и managed services, вместо того чтобы переписывать инфраструктуру под enterprise-облака. В статье разбираем реальные сценарии: что хостить на droplets, когда к ним прикручивать managed базы и load balancer, и где проходят границы платформы.
Три сценария, где droplets работают лучше всего
Первый сценарий - MVP и ранняя стадия продукта. На этом этапе важны две вещи: скорость итераций и предсказуемость денег. Droplet за 6 или 12 долларов в месяц с 1-2 vCPU и 1-2 ГБ RAM несёт на себе demo, лендинг и API с сотнями пользователей. Создание крошечной машины через doctl compute droplet create --image ubuntu-24-04-x64 --size s-1vcpu-1gb --region fra1 demo-01 занимает минуту, а дальше уже привычные cloud-init, docker compose и nginx. Когда пользователей стало много, дроплет просто ресайзят: doctl compute droplet-action resize в больший s-2vcpu-4gb, и продукт продолжает расти без миграции.
Второй сценарий - типовое веб-приложение средней нагрузки: backend API, фронтенд, фоновые воркеры. Это уже не один дроплет, а схема: два идентичных дроплета за load balancer, отдельный дроплет под воркеры, отдельная управляемая база PostgreSQL. Такая схема держит тысячи RPS при правильной организации, а её цена остаётся на уровне сотен долларов в месяц, что для стартапа вдвое-втрое дешевле сопоставимой связки на AWS с учётом трафика.
Третий сценарий - окружение разработки и CI-раннеры. Дроплеты создаются по расписанию, прогоняют интеграционные тесты и уничтожаются. doctl compute droplet create и delete идемпотентны, легко оборачиваются в скрипт, и это отличная замена сидящему в углу офиса тестовому серверу, который кто-то забыл выключить в пятницу.
База данных, droplet против managed
У стартапа база обычно начинается прямо на дроплете: PostgreSQL в docker-контейнере рядом с приложением. Это работает, пока база маленькая и редко пишется. Но на дроплете ответственность за бэкапы, точку восстановления и апгрейды лежит на вас. Когда база становится критичной - это, честно говоря, уже повод переехать на managed.
У DigitalOcean есть managed PostgreSQL, MySQL, Redis (в варианте Managed Caching), Kafka и MongoDB. Ключевые практические моменты. Первое: managed PostgreSQL включает автоматические бэкапы с point-in-time recovery до 7 дней на базовом уровне и дальше при оплате хранилища. Второе: failover в managed-кластере из двух нод занимает секунды и автоматически переключает endpoint в connection string - приложение об этом не должна знать, если используется пул соединений. Третье: connection pooling через встроенный PgBouncer доступен из коробки в managed PostgreSQL, и его включают почти всегда, потому что serverless и edge-функции иначе выжгут max_connections.
Ценовая картина: один крупный дроплет с PostgreSQL стоит заметно дешевле managed-кластера сопоставимой памяти. Но managed выкупает у вас ночные инциденты: авто-фейловер, бэкапы, обновления минорных версий, мониторинг. Для продакшена с реальными клиентами это почти всегда оправдано. Для staging и вспомогательных баз - дроплет с PostgreSQL всё ещё норм.
Load balancing, volumes и spaces, сборка контура под нагрузку
Load balancer на DigitalOcean стоит фиксированные деньги в месяц и поддерживает HTTP/HTTPS с termination прямо на балансировщике, health checks и sticky sessions. Реальная схема: DNS A-запись указывает на LB, LB балансирует на два дроплета, health check идёт на /healthz приложения, и при непрохождении дроплет выпадает из ротации за 10-15 секунд. Базовая защита от DDoS на уровне сети включена по умолчанию.
Диски. У дроплета локальный SSD достаточен для ОС и приложения, но для персистентных данных используют volumes - сетевые блочные устройства, аналог EBS. Volume можно отстегнуть от одного дроплета и пристегнуть к другому, что удобно для миграций: данные остаются при замене машины. Файловая система на вольюме обычно ext4, и после увеличения размера через панель её расширяют вручную resize2fs, потому что сама по себе она не растёт.
Для статики и медиа есть Spaces - S3-совместимое хранилище. Работает с aws-cli через --endpoint-url=https://fra1.digitaloceanspaces.com и с любым S3 SDK. Для интеграции с приложением часто используют паттерн presigned URLs: backend выпускает подписанный URL на загрузку, и клиент грузит медиа напрямую в Spaces, минуя сервер приложения. Это выдерживает большой трафик загрузок без масштабирования дроплетов.
Реальная сборка, от прототипа к продакшену без боли
Хорошая практика: держать код инфраструктуры одинаковым для dev, staging и prod, с параметризацией размера. В Terraform провайдер digitalocean/digitalocean, и конфигурация дроплета с managed базой выглядит предсказуемо:
resource "digitalocean_droplet" "app" {
name = "app-01"
size = "s-2vcpu-4gb"
image = "ubuntu-24-04-x64"
region = "fra1"
user_data = file("bootstrap.yml")
}
resource "digitalocean_database_cluster" "pg" {
name = "app-db"
engine = "pg"
version = "16"
size = "db-s-2vcpu-4gb"
region = "fra1"
node_count = 2
}
Обратите внимание на region: и дроплет, и база должны жить в одном регионе, чтобы ходить по private network. В настройках дроплета включается private networking (это флаг при создании, позже включить можно, но это требует остановки). Междроплетный трафик внутри региона по приватной сети не тарифицируется как исходящий, и это ещё один плюс к предсказуемости счёта.
Мониторинг и эксплуатация без лишних систем
Маленькой команде не нужен тяжёлый стек наблюдаемости на старте. Достаточно внешнего монитора доступности сайта, простых health-check алертов и базовых метрик самого дроплета. В DigitalOcean графики по CPU, памяти, диску и сети показываются в панели по умолчанию, без агентов. Для алертинга настраивают правила: CPU выше 90% в течение 5 минут, диск заполнен на 85%, свободная память меньше 200 МБ. Уведомления идут на email или в Slack.
Для приложений добавляют лёгкий стек: node_exporter на каждом дроплете собирает системные метрики, а Prometheus с Grafana разворачиваются либо на отдельном маленьком дроплете, либо в виде внешнего сервиса. На этапе до 5-10 серверов это обычно избыточно: достаточно логов через journald с отправкой в Loki или в managed хранилище логов. Практический ориентир: если команда тратит на поддержку мониторинга больше времени, чем на продукт, значит система наблюдаемости слишком сложная для текущего масштаба.
Логи приложений с дроплетов собирают просто: stdout в journald, затем promtail читает journal и шлёт в Loki. Для первых месяцев достаточно поднять Loki на том же дроплете, где живёт Grafana: это один маленький сервер за 6 долларов, и он несёт логи десятка сервисов. Когда объём логов переходит сотни гигабайт в день - уже имеет смысл смотреть на managed варианты, но на этапе стартапа это далёкая проблема.
Безопасность и бэкапы без фанатизма
Базовая гигиена применима к любому дроплету. Отключить вход по паролю и вход root по SSH, оставив только ключи: в /etc/ssh/sshd_config выставляется PasswordAuthentication no и PermitRootLogin no. Включить ufw и открыть только 22, 80 и 443: ufw allow 22/tcp, затем 80 и 443, затем ufw enable. Поставить fail2ban для SSH. Регулярные обновления безопасности через unattended-upgrades с автоматическим применением только security-патчей, а не всех обновлений, чтобы не словить regression в проде.
Для доступа к managed базе трафик шифруется TLS и разрешён только с приватной сети. В managed PostgreSQL это включается одним флагом trusted sources, куда вносятся дроплеты приложения. Прямой доступ с публичного интернета к базе надо явно закрыть: это самая частая ошибка новичков - оставить 5432 открытым всему миру и поймать сканирование за первые часы жизни машины.
О бэкапах отдельно. У дроплета есть автоматические еженедельные бэкапы за 20% от цены droplet, и их стоит включить, даже если есть managed бэкапы базы: бэкап дроплета позволяет поднять всю машину целиком после тотальной неудачи. Плюс раз в квартал стоит сделать drill: реально восстановить дроплет из последнего снапшота и проверить, что приложение поднялось само, а не после загадочных ручных правок. Бэкап, который ни разу не был восстановлен, нельзя считать бэкапом.
Деплой и интеграция с CI
В маленькой команде деплой обычно делается без тяжёлого Kubernetes. Схема простая: репозиторий в GitHub, Actions собирает docker-образ, пушит в DigitalOcean Container Registry, а затем SSH-ом заходит на дроплет и дёргает docker compose pull && docker compose up -d. Для стартапа этого достаточно месяцами. SSH-доступ из Actions делается через deploy key, который лежит в Secrets репозитория, а на дроплете тот же ключ прописан в authorized_keys у пользователя deploy с правами на docker без sudo.
Когда дроплетов становится больше одного, скрипт ходит по списку и обновляет каждый, а балансировщик сам убирает дроплет из ротации на время деплоя через health check. Простая стратегия rolling без лишних систем: деплой на один дроплет, проверка, деплой на второй. Для отката достаточно запушить предыдущий тег образа и повторить процедуру. Это выглядит примитивно по сравнению с canary deployments в больших платформах, но оно честно работает и не требует поддержки.
Из универсальной дисциплины на этой стадии полезно следующее. Версии образов тегируются по git SHA, а не latest, чтобы откат был однозначным. Миграции базы запускаются отдельным jobом перед раскаткой новой версии приложения, чтобы порядок не зависел от того, какой дроплет обновился первым. И время деплоя замеряется: если раскатка занимает больше пяти минут, значит пора либо уменьшать образ, либо переходить к более изощрённой схеме, но это уже признак роста, а не проблема.
Границы платформы, когда DigitalOcean перестаёт хватать
Разумно заранее знать, когда платформа упирается в потолок. Первый признак - compliance и география: если требования велят оставлять данные в конкретной юрисдикции, а у DigitalOcean там нет дата-центра, вариантов нет. Второй признак - очень специфические managed-сервисы: вам нужен управляемый Airflow, готовые ML-платформы, глобальный CDN с тонкими правилами и edge-compute - всё это уровня AWS или GCP. Третий признак - трафиковые нюансы: у дроплета есть лимит исходящего трафика в месяц в зависимости от тарифа, а за превышение снимают отдельную плату. Для очень тяжёлой выдачи, сотни терабайт в месяц, цену просчитывают заранее, а не по факту счёта.
Итоговая картина для стартапа складывается так. Начинайте с простого: один дроплет, managed PostgreSQL, Spaces под статику, load balancer при первых признаках роста. Автоматизируйте через Terraform, чтобы каждый элемент можно было пересоздать из кода. Смотрите на фактический счёт ежемесячно и сравнивайте с альтернативами только по факту, а не по прайсу. Тогда DigitalOcean останется не временным костылём на этапе MVP, а надёжным домом для продукта, пока его требования к инфраструктуре не перерастут модель "дроплеты плюс managed services".
И ещё одна практическая привычка, которая окупается с первого месяца: записывайте все ручные действия с инфраструктурой в runbook, даже если всё автоматизировано. Когда в два часа ночи нужно срочно добавить дроплет или сменить тариф, половина команды уже спит, и простой пошаговый текст экономит нервы сильнее любого README в репозитории.
Отдельно стоит отметить культуру малых инкрементов: меняйте инфраструктуру маленькими правками, по одному ресурсу за раз, и проверяйте результат на staging до продакшена. На маленькой платформе вроде DigitalOcean это работает особенно хорошо, потому что цена ошибки здесь ровно одна строка в Terraform и пять минут на пересоздание дроплета, а не многодневная миграция между облаками.