Git-based deployment turns a source-control change into a repeatable application release. Instead of copying files to a server manually, the platform watches a repository, builds the selected revision, deploys it, verifies the new runtime, and keeps release history available for rollback.
For a small team, the practical workflow is:
commit
→ push
→ build
→ deploy
→ health check
→ observe
→ keep rollback target
Raff Technologies Apps supports GitHub push-to-deploy, Dockerfile builds, automatic buildpack detection, immutable revisions, one-click rollback, preview environments, background workers, cron jobs, persistent volumes, managed service bindings, and scale-to-zero. That makes Git deployment a first-class App Platform workflow rather than a shell script copied between servers.
This guide explains where native Git deployment fits, when a separate CI/CD pipeline is still useful, and what a small team should verify before letting every push affect production.
Git deployment changes the release boundary
Manual server deployment usually looks like:
SSH
→ git pull / copy files
→ install dependencies
→ restart process
→ hope local state is correct
Git-based platform deployment moves those steps into a repeatable build-and-release system:
Git repository
→ platform build
→ immutable revision
→ runtime
→ domain
The important difference is not simply "GitHub integration." It is that the deployed revision can be identified and rebuilt without depending on one operator's terminal history.
Native Git deployment vs CI/CD pipeline
Native Git deployment and CI/CD overlap but are not identical.
| Model | Best fit | Main advantage | Main trade-off |
|---|
| Native Git deployment | Small teams, straightforward apps | Minimal pipeline maintenance | Fewer custom gates |
| CI/CD → App Platform | Tests, approvals, multi-stage releases | More control over release policy | More pipeline configuration |
| Manual server deployment | Exceptional/admin workflows | Maximum low-level control | Weak repeatability if not automated |
A useful small-team model is:
pull request
→ CI tests
→ merge to deployment branch
→ app platform deploy
CI validates the change; the platform owns the build/runtime release.
For VM-based deployment automation, keep using CI/CD for VM Deployments. LC14 owns the App Platform side of the boundary.
Choose the deployable unit
Before connecting a repository, define what the platform should build.
Common choices include:
- repository root;
- subdirectory in a monorepo;
- Dockerfile;
- automatically detected runtime/buildpack;
- prebuilt image where the platform supports it.
For Raff Apps, the current live product supports automatic buildpacks and Dockerfile-based builds. It also supports Docker Compose import for multi-service stacks.
Do not add a Dockerfile only because containers sound more production-ready. If the buildpack correctly detects the runtime and produces the environment you need, the simpler path can be appropriate.
Keep the build reproducible
A Git-triggered deployment is only as deterministic as the build inputs.
Lock dependencies:
package-lock.json, pnpm-lock.yaml, or equivalent for Node.js;- pinned Python dependency files;
go.mod / go.sum;- Composer lock files;
- fixed base-image tags or digests where appropriate.
Avoid builds that depend on an unpinned "latest" toolchain without reason.
The goal is:
The same revision should produce the same intended application behavior.
Separate configuration from source code
The repository should not contain production secrets.
Use platform environment variables or secret-management features for:
- database URLs;
- API keys;
- application secrets;
- object-storage credentials;
- environment names;
- feature configuration.
Treat configuration changes as release-relevant changes even when source code did not change.
A rollback to old code may still fail if the environment or database schema has moved forward incompatibly.
Decide what a push should deploy
Do not let every branch behave like production.
A common model is:
feature branch → CI / preview
main → production
Or:
feature branch → preview
staging → staging
main → production
The exact branches matter less than having a documented promotion model.
For the broader environment architecture, use Staging vs Production vs Development Environments.
Preview environments reduce merge risk
Raff Apps currently supports isolated preview environments for pull requests.
A preview can give reviewers:
- a live URL;
- the proposed application version;
- isolated services;
- isolated databases where configured;
- automatic updates on subsequent pushes.
Preview environments are useful when visual behavior, API integration, or database-backed workflow is difficult to review from a code diff.
They are not a replacement for automated tests.
Health checks should gate release confidence
A successful build is not proof that the deployed application works.
Verify:
- process starts;
- expected port is bound;
- health/readiness endpoint succeeds;
- critical dependency configuration is valid;
- public URL serves the expected revision.
If the platform supports automatic health behavior, still define what application-level readiness means.
Use Server Health Checks Explained for the health model.
Keep rollback independent from rebuild
A production rollback should not require rebuilding an old commit from scratch during an incident.
Raff Apps currently uses immutable revisions and supports one-click rollback.
That creates a cleaner recovery model:
bad revision
→ select previous known-good revision
→ rollback
→ verify health
Database migrations and external side effects still require separate compatibility planning.
For release safety beyond the platform itself, see Production Deployment Strategies for SaaS Apps.
Build logs and runtime logs solve different problems
A failed deployment can fail during:
- source checkout;
- dependency resolution;
- compilation/build;
- image creation;
- startup;
- health check;
- runtime request handling.
Keep build logs separate from runtime logs so the team can identify the failure stage quickly.
A runtime failure after a successful build is not a build-system problem.
Monorepos need an explicit service boundary
A monorepo can contain several deployable services:
/apps/web
/apps/api
/workers/email
/packages/shared
Each service should have an explicit:
- build context;
- startup command/runtime;
- configuration;
- deployment trigger;
- health check;
- dependency relationship.
Avoid redeploying every service for every repository change unless that is intentional.
Git deployment does not remove supply-chain risk
Connecting a repository gives code changes a path toward production.
Protect:
- repository write access;
- branch rules;
- deployment credentials;
- third-party actions/integrations;
- dependency sources;
- secret access.
A compromised repository or dependency can become a production deployment path.
Use Developer Supply Chain Security for the broader control model.
A native App Platform deploy is a strong fit when the application:
- has a clear build;
- exposes a normal web/worker process;
- externalizes persistent state;
- reads configuration from environment variables/secrets;
- can be restarted/replaced;
- has a health signal.
A VM may remain simpler when the workload requires:
- custom OS packages or daemons beyond the platform model;
- unusual networking;
- host-level access;
- tightly coupled local state;
- operational control below the application runtime.
Use Cloud VM vs App Platform for that decision.
Git deployment checklist
Before enabling production push-to-deploy:
- dependencies are locked;
- production secrets are outside Git;
- deployment branch is intentional;
- CI checks run before production promotion;
- build context is correct;
- startup command is correct;
- health check is defined;
- database migrations are compatible;
- previous revision is available;
- rollback procedure is known;
- logs are visible;
- preview/staging behavior is documented.
Frequently asked questions
What is Git-based deployment?
Git-based deployment connects a source repository to a deployment system so a selected push, merge, or revision can trigger a repeatable build and release.
Is Git deployment the same as CI/CD?
No. Native Git deployment can handle build and release while a CI/CD system adds custom tests, approvals, security checks, and promotion logic.
Does Raff Apps deploy from GitHub?
Yes. The current Raff Apps product supports GitHub push-to-deploy as well as CLI deployment.
Does Raff Apps require a Dockerfile?
No. Raff Apps supports automatic buildpack detection as well as Dockerfile builds.
Can I roll back a Git deployment?
Yes. Raff Apps currently keeps immutable revisions and supports rollback to a previous revision. Data/schema compatibility still needs separate planning.
Are preview environments available?
Yes. Raff Apps currently supports pull-request preview environments with isolated application stacks.
Sources
