fly io 무료배포 총정리: 무료로 시작하는 배포 절차

fly io 무료배포는 신규 계정에 주어지는 사용 한도 안에서 소규모 애플리케이션을 실제로 띄워 보는 방식으로 시작해요. 다만 무료 한도와 과금 기준은 시점에 따라 조정되므로, 배포 전에 공식 가격 문서에서 현재 조건을 확인하는 편이 안전해요. 이 글은 그 확인 절차와 함께 flyctl 기반의 배포 흐름을 순서대로 정리해요.

한눈에 보기

• fly io 무료배포의 핵심은 "앱을 만들고, 머신을 띄우고, 필요할 때 멈춘다"는 흐름이에요.
• 무료 사용 범위는 고정된 상품이 아니라 계정 상태와 공지 시점에 따라 달라지므로, 공식 가격 문서가 유일한 기준이에요.
• 배포 자체는 명령 몇 번으로 끝나지만, 과금·리전·시크릿 관리는 별도로 챙겨야 해요.
• 데이터베이스가 필요해지는 순간부터는 "무료인가"보다 "운영 비용이 감당 가능한가"로 판단 기준을 바꿔야 해요.

fly io는 컨테이너 이미지를 받아 여러 리전에 머신을 배치하는 구조를 가지고 있어요. 그래서 전통적인 PaaS처럼 "앱 하나 올리면 끝"이라기보다, 앱과 머신과 볼륨을 각각 이해해야 과금도 예측할 수 있어요. 무료배포를 시도할 때 사고가 나는 지점은 대부분 배포 명령이 아니라, 배포한 뒤에 남아 있는 리소스를 방치하는 쪽이에요.

무료 사용 범위와 과금 구조

fly io의 요금은 사용량 기반으로 설계되어 있어요. 계정에 체험 목적의 크레딧이나 소규모 사용 한도가 안내되는 경우가 있지만, 그 조건과 규모는 공지에 따라 조정돼요. 따라서 "무료로 어디까지 가능한가"는 문서에 적힌 고정 표를 외우는 방식보다, 공식 가격 페이지와 대시보드의 사용량 화면을 함께 보는 방식으로 판단해야 해요.

특히 무료 범위를 이야기할 때 자주 혼동되는 것이 컴퓨팅 자원과 부가 자원의 구분이에요. 머신을 띄우지 않아도 볼륨이나 스냅샷, 네트워크 트래픽 같은 항목이 별도로 계산될 수 있어요. 즉 "앱을 안 켰으니 무료"라고 단정할 수 없고, 남아 있는 리소스를 함께 봐야 해요.

표에서 알 수 있듯이, 무료배포의 성패는 "얼마나 싸게 띄우는가"보다 "무엇이 남아 있는가"에 달려 있어요. 배포를 마친 뒤에는 대시보드에서 앱, 머신, 볼륨, IP 할당 상태를 한 번씩 확인하는 습관이 필요해요.

배포 전 준비물

시작 전에 정리해야 할 것은 크게 네 가지예요. 첫째, flyctl이라는 공식 CLI 도구예요. 문서의 설치 안내를 따라 운영체제에 맞는 방식으로 설치하면 돼요. 둘째, fly io 계정과 인증 상태예요. CLI에서 로그인과 가입을 처리할 수 있고, 이 과정에서 결제 수단 등록을 요구받을 수 있어요.

셋째, 애플리케이션의 빌드 방식이에요. Dockerfile이 있으면 그대로 쓰고, 없으면 공식 빌더가 언어를 감지해 이미지를 만들어요. 자동 감지가 잘 맞지 않는 프로젝트는 Dockerfile을 직접 두는 편이 결과를 예측하기 쉬워요. 넷째, 설정 파일이에요. fly launch를 실행하면 fly.toml이 생성되고, 여기에 앱 이름, 리전, 포트, 헬스 체크 같은 값이 들어가요.

준비 단계에서 함께 점검하면 좋은 항목은 다음과 같아요.

• 애플리케이션이 환경 변수만으로 설정을 받아들이는지
• 상태를 로컬 디스크에만 저장하지 않는지
• 헬스 체크에 응답할 경로가 있는지
• 로그를 표준 출력으로 남기는지

이 네 가지가 갖춰지면 배포 후 문제를 추적하기가 훨씬 수월해요.

단계별 배포 방법

절차는 공식 문서의 안내 흐름을 그대로 따라가면 돼요. 아래는 일반적인 순서예요.

1. CLI 설치와 로그인: flyctl을 설치하고 계정으로 인증해요. 인증이 끝나면 이후 명령이 같은 세션에서 동작해요.
2. 프로젝트 디렉터리에서 실행: 애플리케이션 루트에서 fly launch를 실행해요. 앱 이름, 리전, 필요한 부가 리소스를 묻는 과정이 이어져요.
3. 설정 파일 검토: 생성된 fly.toml에서 내부 포트, 서비스 포트, 헬스 체크, 자동 중지 관련 설정을 확인해요. 여기서 잘못된 포트를 두면 배포는 성공해도 접속이 안 돼요.
4. 시크릿 주입: 데이터베이스 접속 정보나 API 키는 fly secrets set으로 넣어요. 파일로 커밋하지 않는 것이 원칙이에요.
5. 배포 실행: fly deploy로 이미지를 빌드하고 머신에 반영해요. 빌드 로그가 길게 올라오니 실패 지점을 함께 읽어야 해요.
6. 상태 확인: fly status와 fly logs로 머신 상태와 애플리케이션 로그를 확인해요. 기본 도메인으로 접속해 응답까지 확인하면 1차 검증이 끝나요.
7. 정리: 테스트가 끝난 앱은 fly apps destroy로 제거해요. 이 단계를 빼먹으면 사용하지 않는 리소스가 계속 남아요.

배포 후 설정을 바꾸고 싶다면 fly.toml을 수정하고 다시 fly deploy를 실행하면 돼요. 리전을 추가하거나 머신 수를 조정하는 작업은 fly scale 계열 명령으로 처리하고, 변경 후에는 다시 사용량 화면을 확인하는 습관이 좋아요.

상황별 선택 가이드

무료배포를 고민하는 이유는 사람마다 달라요. 상황별로 판단 기준을 정리하면 다음과 같아요.

토이 프로젝트나 포트폴리오라면 fly io는 좋은 선택이에요. 컨테이너 기반이라 로컬에서 돌던 것을 거의 그대로 올릴 수 있고, 기본 도메인이 제공되어 시연 링크를 바로 만들 수 있어요. 다만 시연이 끝난 뒤 앱을 정리하는 절차를 꼭 넣어두세요.

사내 데모나 짧은 검증이라면 자동 중지 설정을 활용하는 편이 비용에 유리해요. 대신 첫 요청에서 기동 시간이 붙어 응답이 느려질 수 있으니, 데모 직전에 한 번 호출해 머신을 깨워두는 방식이 자주 쓰여요.

상시 운영 서비스라면 무료 범위를 전제로 설계하지 않는 편이 안전해요. 트래픽이 늘면 머신과 대역폭이 함께 늘고, 그만큼 비용도 선형으로 올라가요. 이 경우에는 예산 상한과 알림을 먼저 정하고 배포하는 순서가 맞아요.

데이터베이스가 필요하다면 관리형 옵션의 제공 형태와 과금 방식을 문서에서 먼저 확인하세요. 애플리케이션은 무료 범위 안이어도 데이터 계층에서 비용이 발생할 수 있어요.

콜드 스타트에 민감한 서비스라면 무료 범위에 맞추기보다 최소 실행 상태를 유지하는 쪽이 사용자 경험에 유리해요. 이때는 무료 여부보다 지연 허용 범위를 기준으로 결정해야 해요.

주의할 점

무료배포에서 가장 흔한 사고는 예상하지 못한 과금이에요. 사용량 기반 구조에서는 머신을 여러 리전에 두거나, 볼륨을 여러 개 붙이거나, 트래픽이 몰리는 순간 비용이 빠르게 올라갈 수 있어요. 대시보드의 사용량 알림을 켜두고, 배포 직후와 며칠 뒤에 한 번씩 확인하는 것을 권해요.

두 번째는 자동 중지와 헬스 체크의 조합이에요. 자동 중지를 켜두면 유휴 시 머신이 내려가고, 요청이 오면 다시 올라와요. 이 동작 자체는 정상이지만, 헬스 체크 경로가 잘못되어 있으면 머신이 계속 재시작을 반복할 수 있어요.

세 번째는 시크릿 관리예요. 접속 정보를 fly.toml이나 이미지에 넣으면 저장소 이력에 남아요. 반드시 시크릿 명령으로 주입하고, 노출이 의심되면 값을 교체하세요.

네 번째는 정리 습관이에요. 테스트용 앱을 만든 뒤 그대로 두면 머신과 볼륨이 계속 유지돼요. 프로젝트 단위로 "만들면 지운다"를 규칙으로 삼는 편이 좋아요.

다섯 번째는 빌드 재현성이에요. 자동 감지 빌더는 편하지만, 언어 버전이나 시스템 패키지가 바뀌면 결과가 달라질 수 있어요. 운영에 가까운 환경이라면 Dockerfile로 빌드를 고정하는 편이 안전해요.

자주 묻는 질문

fly io는 정말 무료로 배포할 수 있나요?

계정에 부여되는 사용 한도 안에서는 소규모 앱을 실제로 배포해 볼 수 있어요. 다만 한도의 범위와 조건은 공지에 따라 조정되므로, 시작 전에 공식 가격 문서에서 현재 기준을 확인해야 해요. "영구 무료"라는 전제로 설계하기보다 체험과 검증용으로 이해하는 편이 정확해요.

무료 한도를 넘으면 어떻게 되나요?

사용량 기반 과금이 적용되어 초과분이 청구될 수 있어요. 그래서 배포 전에 결제 수단과 알림 설정을 확인하고, 테스트가 끝나면 앱과 볼륨을 정리하는 절차를 함께 준비하는 것이 좋아요. 대시보드의 사용량 화면을 주기적으로 보는 습관이 가장 확실한 예방책이에요.

카드 등록 없이 시작할 수 있나요?

가입과 CLI 로그인 과정에서 결제 수단 등록을 요구받을 수 있어요. 시점에 따라 정책이 다르므로, 카드 없이 진행 가능한지는 공식 문서의 가입 안내를 직접 확인하는 편이 빨라요. 등록을 피하려고 우회하기보다, 등록 후 알림과 정리 규칙을 함께 설정하는 쪽을 권해요.

배포는 성공했는데 접속이 안 되면 어디부터 봐야 하나요?

먼저 fly.toml의 내부 포트와 서비스 포트가 애플리케이션이 실제로 듣는 포트와 일치하는지 확인하세요. 다음으로 fly status에서 머신이 정상 상태인지, fly logs에서 기동 오류가 없는지 봐요. 헬스 체크 경로가 응답하지 않으면 머신이 계속 재시작될 수 있으니 이 순서로 좁히면 대부분 원인이 드러나요.

테스트가 끝난 앱은 어떻게 정리하나요?

fly apps destroy로 앱을 제거하면 연결된 리소스도 함께 정리할 수 있어요. 다만 볼륨처럼 별도로 관리되는 자원이 남아 있는지 대시보드에서 확인하는 것이 안전해요. 정리 후에는 사용량 화면에서 과금 항목이 사라졌는지 한 번 더 확인하세요.

여러 리전에 배포하면 무료 범위에 영향이 있나요?

리전을 늘리면 그만큼 머신이 추가되어 사용량이 늘어나요. 무료 범위를 지키고 싶다면 우선 한 리전에서 검증하고, 지연이나 가용성이 문제가 될 때 확장하는 순서가 합리적이에요. 확장 전후로 사용량 변화를 비교하면 비용 예측이 쉬워져요.

출처

• fly io 공식 문서: https://fly.io/docs/
• fly io 요금 안내: https://fly.io/docs/about/pricing/
• fly io 배포 가이드: https://fly.io/docs/launch/
• flyctl 명령 참조: https://fly.io/docs/flyctl/

배포 플랫폼을 고를 때는 무료 여부만 보지 말고, 장애가 났을 때 로그와 상태를 얼마나 빨리 확인할 수 있는지를 함께 보는 것이 좋아요. 관련해서 배포 플랫폼 비교와 운영 체크리스트 글에서 컨테이너 기반 배포를 운영에 붙일 때 확인해야 할 항목들을 이어서 정리했으니 함께 읽어보세요.