Express.js на Render: развёртывание REST API

Мужчина сидит за столом и печатает на ноутбуке, на экране которого виден код.

Это руководство поможет вам развернуть простое REST API на Express.js, используя Render как провайдера хостинга и PostgreSQL как базу данных. После отказа Heroku от бесплатного тарифа многие разработчики искали альтернативы с бесплатной или недорогой стартовой опцией — Render часто рассматривают как одну из таких альтернатив. Здесь мы пройдём весь путь: от подготовки локального проекта до автоматического деплоя и тестирования в Postman.

Что такое Render?

Render — облачная платформа для хостинга приложений, сайтов и баз данных с упором на простоту использования. Ключевые преимущества:

Удобный интерфейс для деплоя приложений на Node.js, Python и других языках.
Встроенная поддержка управляемых баз данных (PostgreSQL и др.).
Автоматические деплои с интеграцией GitHub/GitLab, откаты и вебхуки.
Поддержка кастомных доменов и бесплатных SSL-сертификатов.

Важно: Render предлагает разные типы сервисов (Web Service, Static Site, Background Worker и т.д.). Для API используйте Web Service.

Кому подходит этот подход

Разработчикам, которые хотят быстро развернуть API без настройки инфраструктуры.
Командам, которым нужна интеграция с Git и автоматические деплои.
Проектам, где важен быстрый старт и минимальные операционные усилия.

Когда Render может не подойти

Если необходима тонкая настройка виртуальной сети, нестандартные kernel-опции или доступ к низкоуровневым ресурсам — потребуется IaaS.
Для сверхвысоконагруженных систем с кастомной оркестрацией контейнеров больше подойдут Kubernetes-кластеры в крупных облаках.

Сравнение с Heroku — тезисы

Простота: оба сервиса ориентированы на быстрый старт, но Render иногда воспринимают как более современный интерфейс.
Масштабирование: Render поддерживает авто-скейлинг; конфигурация проще, чем в чистом IaaS.
Цена: Render предлагает стартовые бесплатные/недорогие опции (проверяйте текущее предложение на сайте).
Ограничения: меньшая гибкость по сравнению с полным облаком (может не подойти для очень специфичных требований).

Подготовка проекта — краткий список требований

Node.js >= 14 (проверьте свою версию)
npm или yarn
Учётная запись на Render и GitHub (или GitLab)
Локальный доступ к терминалу и Postman для тестирования

Создание проекта Express.js и установка зависимостей

Если у вас ещё нет проекта, создайте новый каталог и инициализируйте npm:

mkdir render-express-api
cd render-express-api
npm init -y
npm install express pg knex

Пояснение: knex — это query builder, упрощающий работу с SQL и миграциями; pg — драйвер PostgreSQL для Node.

Структура проекта (рекомендуемая)

index.js — основной файл сервера
db.js — конфигурация подключения к базе
package.json — скрипты запуска
scripts/migrate.js — скрипт создания таблиц
.gitignore — node_modules, .env и т.д.

Конфигурация подключения к базе (db.js)

Создайте файл db.js в корне проекта и добавьте следующий код (вставляйте реальную строку подключения):

const knex = require('knex');
const db = knex({
  client: 'pg',
  connection: {
    connectionString: process.env.DATABASE_URL || 'the database URL',
    ssl: {
      rejectUnauthorized: false
    }
  }
});

module.exports = db;

Пояснение: используем process.env.DATABASE_URL для гибкости — на Render вы будете использовать Internal Database URL в проде и External Database URL локально.

Важно: никогда не коммитьте реальные секреты в репозиторий. Храните URL базы в переменных окружения на Render и в локальном .env для разработки.

Простой Express API (index.js)

Пример простого REST API с четырьмя маршрутами: список пользователей, создание, удаление и корневая точка.

const express = require("express");
const app = express();
const db = require('./db');
const PORT = process.env.PORT || 5000;

app.use(express.json());
app.use(express.urlencoded({ extended: true }));

app.get('/', (req, res) => res.send('Hello World!'));

// Get all users
app.get('/users', async (req, res) => {
  try {
    const users = await db.select().from('users');
    res.json(users);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error retrieving users' });
  }
});

app.post('/users', async (req, res) => {
  try {
    const user = await db('users').insert({ name: req.body.name }).returning('*');
    res.json(user);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error creating user' });
  }
});

// Delete an existing user
app.delete('/users/:id', async (req, res) => {
  try {
    const { id } = req.params;
    const user = await db('users').where({ id }).delete().returning('*');
    res.json(user);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error deleting user' });
  }
});

app.listen(PORT, () => console.log(`Server up at PORT:${PORT}`));

Совет: для продуктивного кода добавьте валидацию входных данных, обработку CORS и уровни логирования.

Скрипт миграции (scripts/migrate.js)

Создайте папку scripts и файл migrate.js:

const db = require('../db');
(async () => {
  try {
    await db.schema.dropTableIfExists('users');
    await db.schema.withSchema('public').createTable('users', (table) => {
      table.increments();
      table.string('name');
    });
    console.log('Created users table!');
    process.exit(0);
  } catch (err) {
    console.log(err);
    process.exit(1);
  }
})();

Этот скрипт создаст таблицу users с автоинкрементным первичным ключом и полем name.

package.json — скрипты

Добавьте в package.json раздел scripts:

"scripts": {
  "start": "node index.js",
  "migrate": "node scripts/migrate.js"
}

Локальная миграция и тестирование

Получите External Database URL в настройках PostgreSQL на Render и вставьте его в локальную переменную окружения DATABASE_URL (например, в .env).
Запустите команду миграции локально:

npm run migrate

Запустите сервер локально и протестируйте через Postman или curl:

npm start
# POST http://localhost:5000/users
# GET  http://localhost:5000/users

Примечание: использование External Database URL позволяет подключиться к базе из вашей локальной машины. После создания таблиц переключитесь на Internal Database URL в настройках Render для подключения внутри платформы.

Главная страница Render на официальном сайте

Создание PostgreSQL на Render

Войдите в аккаунт Render.
На панели управления нажмите кнопку для создания новой базы данных (New PostgreSQL).
Придумайте имя базы и нажмите Create database.
Скопируйте предоставленный Internal Database URL для использования в деплойнутом сервисе.

Информация о новой PostgreSQL базе данных на странице настроек Render

Важно: Internal Database URL используется сервисами, которые работают внутри Render. External Database URL — для внешних подключений.

Деплой на Render — шаги

Создайте репозиторий на GitHub и отправьте туда код проекта.
В Render нажмите New+ → Web Service.

Выпадающее меню с опциями Render, выбран Web Service

Подключите Render к вашему GitHub-репозиторию и выберите проект.

Страница настроек подключения GitHub в Render

На странице настроек веб-сервиса укажите имя сервиса, корневую папку (root directory), билд-команду (если требуется) и команду запуска (например, npm start). Создайте сервис.
В разделе Environment — Environment Variables добавьте DATABASE_URL и поставьте значение Internal Database URL из PostgreSQL-инстанса Render.
Сохраните и дождитесь завершения сборки и деплоя. Скопируйте URL сервиса для тестирования.

Тестирование API на Postman

Сделайте POST-запрос к /users, отправив JSON с полем name.
Убедитесь, что ответ содержит созданного пользователя.
Сделайте GET-запрос к /users и проверьте, что пользователи возвращаются.

Запрос POST к API в Postman

Запрос GET к API в Postman

Безопасность и рекомендации

Не храните секреты в коде. Используйте переменные окружения на Render.
SSL включён по умолчанию для кастомных доменов и служб Render.
Для защиты API используйте аутентификацию (JWT или OAuth) и ограничьте публичный доступ, если это необходимо.

Когда это решение может не сработать (counterexamples)

Если приложение требует нестандартных сетевых настроек (например, приватные VPC-сети), Render может оказаться ограничивающим.
Для приложений с миллионами запросов в минуту может потребоваться более тонкая оптимизация инфраструктуры и распределение нагрузки.
Если вы обязаны использовать конкретные версии ОС/ядерных библиотек — облачный PaaS может не предоставить нужной гибкости.

Альтернативные подходы

Railway: похожая концепция «deploy-first» с простыми базами данных.
Fly.io: геораспределённый хостинг приложений ближе к пользователю.
Vercel: отличный выбор для фронтенд-приложений и serverless-функций.
DigitalOcean App Platform: PaaS-опция с гибкой ценовой политикой.
Собственный кластер Kubernetes на облаке (GCP/AWS/Azure) для полной контроля.

Перенос с Heroku на Render — чеклист миграции

Экспорт данных из Heroku Postgres (pg:backups или pg_dump).
Создать базу на Render и импортировать дамп в PostgreSQL.
Перенести переменные окружения (config vars) в Render — проверьте имена и форматы.
Обновить строки подключения/переменные в проекте.
Настроить сервисы, cron/worker и вебхуки, если они были на Heroku.
Протестировать функциональность в staging перед полной миграцией DNS.

Совет: планируйте окно миграции и проверяйте согласованность данных после импорта.

SOP: стандартная операционная процедура для деплоя на Render

Подготовка изменений в ветке feature/.
Прогон тестов и линтеров локально.
Создание Pull Request и код-ревью.
Слияние в main → Render автоматически запускает билд.
Проверка логов сборки и успешного деплоя.
Smoke-тесты основных endpoint-ов.
Мониторинг метрик и логов в течение 15–30 минут.

План реагирования на инциденты (runbook)

Сценарий: сервис не запускается после деплоя.

Проверить логи сборки и логи runtime в панели Render.
Убедиться, что переменные окружения заданы и DATABASE_URL корректен.
Проверить результат миграций — выполнены ли они, есть ли ошибки создания таблиц.
При ошибке подключения к БД: проверить, не поменялся ли Internal/External URL, открыть доступы и перезапустить сервис.
Если ошибка на уровне кода — откатить на предыдущую стабильную версию (Render поддерживает откаты).
Сообщить команде и задокументировать причину и шаги устранения.

Критерии приёмки

Сервис доступен по публичному URL и отвечает на GET /.
POST /users создаёт запись в базе, GET /users возвращает созданные записи.
Логи не содержат критических ошибок при старте.
Все чувствительные переменные окружения хранятся в Render, а не в репозитории.

Тест-кейсы / Acceptance

POST /users с телом { “name”: “Alice” } → статус 200 и объект пользователя.
GET /users → список содержит объект Alice.
DELETE /users/:id удаляет запись и возвращает удалённый объект.
Негативный тест: POST /users без name → ожидаем обработку (в продакшн добавить валидацию и вернуть 400).

Контрольные показатели качества (минимальные)

Процент успешных ответов: ориентироваться на 99% для небольших проектов.
Среднее время ответа: должно оставаться в пределах ожидаемого для вашей бизнес-логики.

Примечание: конкретные SLI/SLO зависит от требований проекта.

Полезные шаблоны и сниппеты

.env (локально, не коммитить):

DATABASE_URL=postgres://user:pass@host:port/dbname
PORT=5000

package.json — основные скрипты (пример):

{
  "name": "render-express-api",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "start": "node index.js",
    "migrate": "node scripts/migrate.js"
  }
}

Отладка распространённых ошибок

Ошибка подключения к БД: проверьте правильность DATABASE_URL и флаг ssl.rejectUnauthorized=false.
Порт занят или не задан: убедитесь, что используете process.env.PORT, а не жёстко прописанный порт.
Неправильные миграции: проверьте структуру таблиц и права пользователя базы.

Модель зрелости проекта (Maturity levels)

Начальный: код локально, база на Render, ручные миграции.
Средний: CI в GitHub Actions, автоматические миграции при деплое, мониторинг базовых метрик.
Продвинутый: Blue/Green или Canary-деплой, автоматическое масштабирование, централизованный логинг и алерты.

Краткий глоссарий

Render: PaaS-платформа для хостинга приложений.
Internal Database URL: адрес для подключения сервисов внутри Render.
External Database URL: адрес для внешних подключений к базе данных.
Knex: query builder для SQL в Node.js.

Локальные нюансы и подводные камни

Убедитесь, что ваш провайдер Git (GitHub/GitLab) корректно интегрирован с Render, иначе автоматические деплои не сработают.
Проверяйте лимиты бесплатного/начального тарифа Render; для долгосрочных проектов рассмотрите платный план.

Резюме

Развёртывание Express.js API на Render — быстрый и эффективный путь для старта проектов и прототипов. Основные шаги: создать PostgreSQL-инстанс на Render, настроить db.js с использованием переменных окружения, выполнить миграции локально (через External URL), затем подключить Internal URL для продакшн-среды и развернуть Web Service через интеграцию с GitHub. В статье приведены чек-листы, SOP, runbook и тест-кейсы, которые помогут поддерживать стабильный процесс разработки и деплоя.

Важно: обязательно храните секреты в переменных окружения на Render, проверяйте миграции и прогоняйте smoke-тесты после каждого деплоя.

Ключевые материалы: исходный код приложения, миграции, package.json и инструкции по переменным окружения остаются в репозитории; Render используется как площадка для автоматического деплоя и хостинга базы данных.

Развёртывание Express.js REST API на Render