From code to a live application, explained clearly.
Shipploy helps people deploy and operate web applications without needing to become cloud or DevOps experts. These docs explain what to do, why it matters, and what happens behind the scenes.
Start with what you want to achieve
Deploy your first application
Go from a GitHub repository to a secure, public URL in a few guided steps.
Read guide →Understand what Shipploy does
Learn the product in plain language, including environments, releases, costs, and teamwork.
Read guide →Configure and ship safely
Set up builds, variables, domains, deployment rules, logs, and rollbacks.
Read guide →Govern your platform
Manage access, infrastructure, security, observability, billing, and audit history.
Read guide →Deploy your first application
You need a Shipploy account and a GitHub repository. Most of the work happens in the dashboard; you do not need to configure a server or write a deployment pipeline first.
- 1
Create your workspace
A workspace is the home for your team, applications, access rules, and billing. Use your company or team name.
- 2
Connect an application
Select New project, connect GitHub, and choose a repository. A project in Shipploy represents one application.
- 3
Create an environment
Start with Production, or add Development and Staging first. Choose the branch that belongs in each environment.
- 4
Add configuration
Add required environment variables, confirm the application port and health-check path, then review the deployment settings.
- 5
Deploy and open the URL
Select Deploy. Follow the live log until the status becomes Ready, then open the generated Shipploy URL.
How Shipploy works
Think of Shipploy as the release manager between your source code and the people using your application. It coordinates the infrastructure while keeping the important decisions visible to your team.
The Shipploy structure
Your organization. It contains people, projects, policies, infrastructure, and billing.
One application, such as your website, API, customer portal, or internal tool.
A stable destination such as Development, Staging, or Production, with its own settings and URL.
An exact, unchangeable version of your application created from a commit or container image.
Projects
A project connects Shipploy to the source of one application. It stores how the application should be built, which team members can deploy it, and how repository events should trigger releases.
Ways to deploy
From Git
Connect a repository and branch. Shipploy clones the selected commit, builds it using your Dockerfile or detected settings, and creates a release.
From a Docker image
Use an image that is already built and stored in a container registry. Shipploy pulls it and starts it with your environment configuration.
Automatic deployments
Branch rules connect Git activity to environments. For example, pushes to develop can update Development, while pushes to main update Production. Pull requests can create temporary preview environments for review.
Environments
Environments let one application exist in several safe stages. Each stage has its own branch, variables, resources, domain, health check, and release history.
| Environment | Use it for | Typical audience |
|---|---|---|
| Development | Frequent changes and early testing | Developers |
| Preview | Reviewing one pull request or feature | Developers, designers, stakeholders |
| Staging | Final checks in a production-like setup | QA and product teams |
| Production | The version used by real customers | Everyone |
Deployments
Every deployment records the source version, who started it, its configuration, build output, health, timestamps, and result. This history makes releases understandable and recoverable.
Your deployment is waiting for capacity.
A workspace owner or admin must approve the exact release.
Shipploy is turning the source code into a runnable application.
The new version is starting and being connected to traffic.
The release is healthy and available at its URL.
Something stopped the release; logs explain what happened.
Actions you can take
- Redeploy runs the release process again using the selected version.
- Restart restarts the running application without rebuilding it.
- Cancel stops a release that is still in progress.
- Rollback restores a previously healthy deployment.
- Promote moves a verified blue/green or canary candidate to live traffic.
Domains and HTTPS
A ready environment receives a Shipploy hostname. You can also connect a domain your organization owns, such as app.example.com.
- Add the domainOpen the environment’s Domains area and enter the hostname.
- Prove ownershipAdd the TXT record shown by Shipploy to your DNS provider.
- Connect trafficAdd or sync the requested A, alias, or CNAME record.
- Confirm HTTPSWait for DNS and certificate changes to finish, then test the public URL.
Variables and secrets
Variables configure an application without changing its code. They often contain database addresses, API endpoints, feature settings, and sensitive credentials.
- Use a different value for each environment.
- Rotate credentials regularly.
- Give secrets only to people and services that need them.
- Check logs for accidental exposure.
- Committing secrets to Git.
- Sharing production values in chat or screenshots.
- Reusing one credential everywhere.
- Printing secrets during a build.
People and permissions
Workspace roles make responsibility clear. Give each person the least access they need, and use project-level collaboration when someone should work on only one application.
| Role | Best for | Access |
|---|---|---|
| Owner | Business or platform owner | Everything, including billing and workspace deletion |
| Admin | Engineering or operations lead | Team, security, infrastructure, approvals, and audit history |
| Developer | Engineers shipping applications | Create and change projects, environments, and deployments |
| Viewer | Product, QA, and stakeholders | Read-only access |
| App identity | Automation | Deploy assigned projects only |
Safe releases
Shipploy provides several ways to reduce release risk. Choose a strategy based on your application’s importance, traffic, and the cost of an interruption.
Replaces the previous running version as the new one becomes healthy. Simple and suitable for routine changes.
Keeps the candidate separate until your team verifies it and promotes it to live traffic.
Introduces the new version to a controlled share of traffic before a wider release.
Approval gates add a human decision before a protected environment changes. The approval is attached to the exact deployment, so a later code change cannot silently reuse an earlier approval.
Costs and billing
Your workspace is the billing boundary. Shipploy can separate platform subscription charges from application usage and infrastructure costs, helping teams understand what each project and environment consumes.
What affects cost
- How long builds run and how often you deploy.
- The CPU, memory, and storage reserved by running applications.
- Data transfer, requests, and cache behavior.
- The number and lifetime of preview environments.
- Shared, dedicated, or customer-owned AWS infrastructure.
Logs and monitoring
Observability answers three practical questions: Is the application healthy? What changed? What should we do next?
Deployment logs
Follow cloning, building, starting, verification, routing, and cleanup. Start at the first clear error, not the final failure message.
Runtime logs
See what the running application reports while handling traffic. Sensitive values are redacted where supported.
Health checks
Shipploy requests a configured path and expects a successful response. This prevents unhealthy releases from being marked ready.
Workspace overview
Review deployment trends, failures, alerts, and host CPU, memory, and disk use from one place.
Troubleshooting
When a deployment fails, read the stage and the first specific error. The symptoms below cover the most common cases.
The build failed +
Confirm the project’s branch, root directory, Dockerfile, build command, and required build-time variables. Reproduce the build locally when possible.
The application starts but never becomes healthy +
Check the internal port and health-check path. The application must listen on all interfaces, not only localhost, and return a successful status from the configured path.
The domain does not open +
Verify the TXT ownership record, routing record, certificate status, and spelling of the hostname. Use the generated Shipploy URL to separate application problems from DNS problems.
A new release broke production +
Open deployment history and roll back to the last healthy version. Preserve the failed deployment and logs for investigation instead of repeatedly redeploying it.
The application runs out of memory or CPU +
Review usage and runtime logs. Increase limits only after checking for a leak, runaway job, or incorrect concurrency setting.
Security
Shipploy combines workspace isolation, role-based access, protected secrets, release records, and infrastructure controls. Your team still owns application security and safe credential practices.
Identity
Email/password and supported OAuth sign-in, with SAML SSO for eligible enterprise workspaces.
Access
Workspace roles, project scoping, approval gates, and audit history.
Data
Masked variables, encrypted credentials when configured, and AWS Secrets Manager references.
Infrastructure
Shared or dedicated compute, network controls, HTTPS, and customer AWS account options.
Technical reference
This layer is for developers and platform operators who need implementation details. The plain-language guides above remain the best starting point for most readers.
Application delivery
Git or OCI image input, Docker-based builds, asynchronous deployment queue, health verification, and immutable release records.
Traffic and DNS
Platform hostnames, custom-domain ownership checks, ALB host routing, Route 53 synchronization, ACM certificates, and release promotion.
Placement
CPU, memory, disk, region, tenancy, and host-affinity aware scheduling across shared or dedicated compute pools.
Automation
GitHub webhooks, scheduled deployments, Stripe billing, generic routing webhooks, email alerts, and AWS services.
Platform health endpoints
Glossary
Short definitions for terms you will see throughout Shipploy.
- Build
- The process of turning source code into a runnable application package.
- CI/CD
- Automation that checks, builds, and releases changes from source control.
- Container
- A portable package containing an application and the software it needs to run.
- DNS
- The internet’s address book; it connects a domain name to the service that answers for it.
- Health check
- An automatic request used to confirm that an application is ready to receive traffic.
- Rollback
- Restoring a previous healthy deployment when a newer release has a problem.
- Secret
- A sensitive configuration value such as a password, token, or private key.
- Webhook
- An automatic message sent between services when an event occurs, such as a Git push.