제한 사항
Free 플랜에 적용되는 제한입니다. 한도에 근접하거나 초과하기 전에 알려드립니다.
현재 모든 조직은 Free 플랜입니다. Pro 열은 셀프서비스 청구가 시작되면 플랜이 어떻게 바뀌는지 보여줍니다. 아래의 모든 제한은 실제로 서비스에서 집행되지만, 한 가지 예외가 있습니다. 데이터베이스 크기는 측정되고 알림이 가지만, 한도에서 쓰기를 거절하지는 않습니다. 대신 어떤 일이 일어나는지는 아래에서 설명합니다.
| 항목 | 무료 | 프로 | 초과 시 |
|---|---|---|---|
| 요청 | 하루 100,000회 | 월 1,000만 건 포함 | 00:00 UTC까지 429 budget_exhausted. |
| CPU 시간 | 하루 1,000초 | 월 3,000만 ms 포함 | 00:00 UTC까지 429 budget_exhausted. |
| 워커 메모리 | 512 MiB | 1 GiB | 워커가 다시 시작되고 runlot logs에 한 줄이 남습니다. |
| 조직당 프로젝트 수 | 3 | 30 | 409 project_limit |
| 프로젝트당 커스텀 도메인 수 | 1 | 50 | 409 hostname_limit |
| 프로젝트당 프리뷰 배포 수 | 2 | 10 | 409 preview_limit |
| 마지막 요청 이후 프리뷰 유지 기간 | 24시간 | 7일 | 프리뷰와 그 데이터베이스 브랜치가 삭제됩니다. |
| 데이터베이스 크기 | 500 MiB | 8 GiB | 쓰기는 계속 동작합니다. 90%에서 알려드립니다. |
| 백업 보존 기간 | 7일 | 30일 | 가장 오래된 백업부터 삭제됩니다. |
| 파일 저장소 | 10 GiB | 100 GiB 포함 | 무료: 507 quota_exceeded. Pro: 업로드는 계속되고 초과분이 청구됩니다. |
| 파일 저장소 초과 사용량 (Pro) | — | 포함된 100 GiB를 넘는 월 평균에 GiB·월당 $0.015 | 지출 한도에 합산됩니다. 한도에 이르면 다음 달 1일까지 업로드가 507 quota_exceeded로 거절됩니다. |
발신 이메일(로그인 이메일 및 env.email.send) | 프로젝트당 시간당 30건 | 시간당 300건 | 전송이 지연됩니다. |
| 수신 이메일 | 프로젝트당 시간당 600건 | 동일 | 발신 서버에 나중에 다시 시도하라고 알립니다. |
| 이메일 로그 보존 기간 | 30일 | 365일 | 가장 오래된 항목부터 삭제됩니다. |
| 로그 버퍼 | 프로젝트당 2,000줄 / 1 MiB | 동일 | 가장 오래된 로그부터 삭제됩니다. |
| 번들 업로드 | 압축 후 64 MiB | 동일 | bundle_too_large |
| 예약 실행 | 조직당 5개 | 250 | 400 cron_limit |
| 큐 | 조직당 5개, 프로젝트당 5개; 프로젝트당 하루 10,000 작업 | 조직당 25개; 하루 1,000,000 작업 | 배포 시 400 queue_limit; send가 QueueLimitError를 던지며 00:00 UTC에 풀립니다. 큐를 참고하세요. |
| 벡터 | 프로젝트당 5,000개, 최대 3,072 차원 | 프로젝트당 25,000개 | upsert가 VectorsError(vector_limit)를 던지고 아무것도 쓰지 않습니다. 상한을 넘겨 자란 네임스페이스는 질의 시점에 거절됩니다. 임베딩과 벡터를 참고하세요. |
| 빌드 시간(푸시하면 배포) | 조직당 월 300분 | 월 3,000분 | 빌드가 minutes_exhausted로 실패하고 이전 배포가 그대로 서비스됩니다. 매달 1일 UTC에 초기화됩니다. |
| 요청 속도 | 클라이언트당 초당 60회(순간 120회), 프로젝트당 초당 2,000회 | 동일 | Retry-After와 함께 429. 요청 속도 제한과 DDoS를 참고하세요. |
데이터베이스 크기 제한은 엔진 제한이 아니라 운영상 제한입니다. 백업은 이전 백업 이후의 커밋만 담으므로, 백업 비용은 데이터베이스 크기가 아니라 쓴 양에 따라 달라집니다 — 이 덕분에 상한이 무료 플랜은 150 MB에서 500 MiB로, Pro는 8 GiB로 올라갔습니다.
현재는 상한에서 쓰기를 막지 않습니다. 90%에 도달하면 db_near_cap 알림을 보냅니다. 자세한 내용은 크기 상한을 참고하세요.
예약 실행에도 한 번의 실행에 대한 실행 시간 상한이 있으며, 이 상한은 요금제가 아니라 일정에서 정해집니다: 1시간 미만이면 30초, 1시간 이상이면 5분입니다. 자세한 내용은 예약 실행을 참조하세요.
파일 저장소 할당량을 초과한 뒤에도 읽기, 목록 조회, 삭제는 계속 작동합니다. 사용량을 다시 줄일 수 있도록 쓰기만 제한됩니다.
워커 메모리는 프로젝트마다 상한이 있고, 이 상한은 그 프로세스가 동시에 들고 있는 전부를 덮습니다 — 작성하신 코드, 만들고 있는 응답 본문, 데이터베이스 엔진의 작업 메모리까지 포함됩니다. 상한을 넘으면 프로세스가 멈췄다가 다시 시작합니다. 그 순간 처리 중이던 요청은 실패하고, 다음 요청은 새 프로세스에서 실행됩니다. runlot logs에 worker exceeded the memory cap (512 MiB) and was restarted 줄이 남으므로, 메모리 때문에 재시작됐다는 사실을 크래시로부터 추측하지 않으셔도 됩니다. 흔한 원인은 파일 하나나 쿼리 결과 전체를 메모리에 올려 두는 것입니다. 스트리밍으로 바꿔 보세요.
프로젝트 한도에 도달했을 때
Error [project_limit] the free plan allows up to 3 projects (currently 3)응답 본문에는 현재 한도와 사용량이 포함됩니다.
{ "error": { "code": "project_limit", "message": "…", "details": { "limit": 3, "count": 3, "plan": "free" } } }더 이상 사용하지 않는 프로젝트를 정리하거나, 더 필요하면 [email protected]로 알려주세요.
알림
한도에 근접하거나 초과하면 조직의 admin에게 알립니다.
| 알림 | 시점 |
|---|---|
project_limit | 프로젝트 생성이 한도로 인해 거부됨 |
db_near_cap | 데이터베이스가 한도의 90%에 도달함 |
storage_near_quota | 파일 저장소가 할당량의 90%에 도달함 |
storage_quota_hit | 파일 저장소 할당량에서 업로드가 거절됨 (무료만 해당. Pro에서 거절은 지출 한도이며, 그 알림은 budget_exhausted입니다) |
backup_failed | 재시도 후 백업이 실패함 |
cron_failed | 예약 실행이 완료되지 못함 |
build_failed | 푸시하면 배포의 빌드가 배포를 만들지 못함(저장소당 한 시간에 최대 한 번) |
restore_done | 복구가 완료됨 |
dns_publish_stalled | DNS 존이 5분 동안 게시되지 않음 |
같은 종류의 알림은 최대 24시간에 한 번만 전송됩니다. 이는 반복되는 초과로 받은편지함이 넘치는 것을 막습니다.
최근 알림은 대시보드의 조직 페이지에서 확인할 수 있습니다. 등록된 이메일 주소가 없는 계정의 경우, 대시보드가 알림이 표시되는 유일한 곳입니다.
요청과 CPU 시간
둘 다 프로젝트가 아니라 조직 단위로 집계되며, 둘 다 집행됩니다.
- 무료 플랜에서는 일일 요청 또는 CPU 예산을 초과하면 해당 UTC 일의 나머지 시간 동안 서빙이 중단됩니다 — 이는 절대 요금 청구로 전환되지 않습니다. 요청에는
429 budget_exhausted와 다음 00:00 UTC를 가리키는Retry-After헤더로 응답합니다. - Pro에서는 포함된 양을 초과한 사용량에 요금이 청구되며, 월별 지출 한도가 기본적으로 설정되어 있습니다. 그 한도에 도달하면 동일한
429가 발생합니다.
두 가지는 의도적으로 열어 두었습니다. psql, runlot pg shell, 드라이버를 통한 데이터베이스 연결은 이 한도의 영향을 받지 않으므로, 언제든 데이터를 꺼낼 수 있습니다. 그리고 정적 자산을 서빙하는 요청도 다른 요청과 똑같이 집계되므로, 무료 할당량으로 감당할 수 있는 페이지 로드는 숫자만 봤을 때보다 적습니다.
집행은 즉각적이지 않습니다. 사용량은 1분에 한 번 보고되며 결정은 다음 맵 폴링에서 트래픽 프론트엔드에 전달되므로, 한도를 넘어서도 2~3분 동안 서빙이 계속될 수 있습니다. 이 유예는 제공되는 것이지 요금이 청구되지 않습니다.
runlot usage
runlot usage --hours 168프로젝트 개요 화면의 그래프
프로젝트의 첫 화면은 저장된 값을 숫자 하나로 요약하지 않고 그대로 그립니다. 측정값 하나에 그래프 하나씩 여섯 개이고, 기간은 24시간, 7일, 30일 중에 고릅니다.
| 그래프 | 무엇인가 | 한도 선 |
|---|---|---|
| 요청 | 프론트엔드가 왕복을 마친 요청입니다. 알 수 없는 호스트 이름, 정지된 프로젝트, 배포 없음 같은 거절은 여기 없습니다. 어느 것도 여러분의 코드를 한 줄도 실행하지 않았기 때문입니다. | 무료: 하루 100,000건 |
| CPU 시간 | 요청과 같은 모집단입니다. | 무료: 하루 1,000초 |
| 데이터베이스 크기 | 노드가 마지막으로 관측한 크기이며, 합이 아닙니다. | 플랜의 상한 |
| 파일 저장소 작업 | 오브젝트 읽기와 쓰기입니다. | — |
| 5xx 오류 | 5xx로 응답한 요청이고, 아래에 요청 대비 비율을 적습니다. 404는 여기 없습니다. 그것은 클라이언트의 실수이고, 누가 주소를 잘못 쳤다고 치솟는 오류 그래프는 볼 이유가 없습니다. | — |
| 응답 시간 | 중간값이며, 아래에 느린 1%를 함께 적습니다. 주차된 프로젝트를 깨우는 시간도 이 숫자 안에 있습니다. 사용자가 겪은 시간이 그려지는 시간입니다. | — |
어떻게 그리는지 몇 가지는 알아 둘 값어치가 있습니다. 믿을 수 있는 그래프와 그냥 그래프의 차이가 거기에 있습니다.
- 7일과 30일에서는 개수 그래프가 하루 단위로 묶입니다. 실제로 있는 한도가 하루 기준이라, 하루치 한도를 시간별 막대 위에 점선으로 그으면 막대가 영영 닿을 수 없는 선이 됩니다. 데이터베이스 크기는 그날의 마지막 관측값을 쓰고 절대 더하지 않습니다. 크기를 시간마다 더하면 같은 저장소를 하루에 스물네 번 세게 됩니다.
- 빠진 시간대는 빈칸으로 둡니다. 보고가 오지 않은 시간대에는 행을 쓰지 않고, 그래프도 채워 넣지 않습니다. 0이 평평한 것과 "보고가 오지 않았다"는 다른 사실이고, 노드가 조용해진 프로젝트는 그렇게 보여야 합니다.
- 세로 점선은 배포입니다. 올려 두면 어느 버전인지 나옵니다. 응답 시간 그래프의 계단이 표식에서 정확히 시작한다면 대개 그 릴리스이고, 그것이 이 표식을 두는 이유입니다.
- 응답 시간은 묶지 않습니다. 백분위수는 더할 수 없으므로 하루의 중간값은 그날 시간대들의 중간값으로 구할 수 없습니다. 이 그래프는 어느 기간에서든 시간 단위 점을 유지하고, 위의 대표 숫자는 서버가 기간 전체를 한 번에 계산한 값입니다.
- 오류율에는 분모가 필요합니다. 기간 안에 요청이 없으면
0.00%가 아니라 줄표를 보여 줍니다.
모든 그래프 아래에는 같은 숫자를 글로 보여 주는 "데이터 표 보기"가 있습니다.
얼마나 이전으로 복원할 수 있나
백업은 자주 생성되고 각 백업은 변경된 부분만 담으므로, 보존 창 안의 어느 시점으로든 복원할 수 있습니다. 무료는 7일, 프로는 30일입니다. 사본을 외부에 보관하는 비용 때문에 플랜별로 보존 기간이 다릅니다.
복원은 보존 기간 안의 어느 커밋으로든 안착합니다 — 백업, 커밋 id, 시각 중 하나로 지정합니다. 백업과 복원을 참고하세요.
리전
현재 리전은 서울 하나뿐입니다. 애플리케이션과 데이터베이스가 같은 머신에서 실행되므로 env.db 호출에 네트워크 왕복이 필요하지 않습니다.