Existing application code
Deploy a new instance first
Microtica builds and deploys your code as a new app. Plan database migration, secrets, DNS and traffic changes before it replaces a production deployment.
Read the application import guideFrom a repository to a live app in your cloud.
Paste a repository, or ask Mica. Approve one plan, and your app is live in your own cloud account. Every push deploys, and releases ship several apps as one.
From GitHub, GitLab or Bitbucket. Or tell Mica what you want to run.
- Demo project
- Welcome
How it works
Three steps and one approval.
The ease of a PaaS, with the app running in your own cloud account.
- 01 · Paste a repository
Paste a repository, or ask Mica
On the first screen after you sign up, paste a GitHub, GitLab or Bitbucket URL, or say what you want to run. Prefer a form? Use the Add page, or start from a template.
Connect what it needs as you go
If Git or your cloud account isn't connected yet, Mica asks for it in the chat. Deploying on every push needs permission to add a webhook to the repository.
What each connection grants - 02 · Approve one plan
Approve one plan
Mica reads the repository and tells you the plan: the repository and branch, how it builds, where it runs, and a deploy on every push. By default Microtica runs it on Amazon ECS, so there's no cluster to set up. Prefer Kubernetes? Pick it on the Add page. Nothing is created until you approve.
No build config to write
Railpack detects the language and builds the image without configuration. If the repository has a Dockerfile at its root, Microtica uses that instead.
How approvals work - 03 · Open your app
Open your app
Microtica sets up what the app needs, adds its pipeline, then builds and deploys it. The launch card in the chat follows it until it's live. After that, every push to the branch deploys again.
If the first build fails
The launch card names the step that failed. Ask Mica why: it reads the build logs, names the cause and proposes the fix, usually a change in the repository. Push it and the app deploys again.
How Mica investigates failures
Where it runs
Your app, the way it fits.
Every option runs in your own cloud account and gets the same deploys, logs and releases. Pick one per app.
Containers, no cluster
Amazon ECS on AWS Fargate
The default for a first app from a repository. It runs behind an HTTPS load balancer and scales with traffic.
- A public HTTPS address generated by AWS, ending in on.aws. Custom domains aren't available here yet.
- Starts with 1 task and scales on CPU up to 3. Change the port, CPU, memory, task counts and variables in the app's settings.
- Each deploy rolls out as a canary and rolls back automatically if 5XX errors rise.
- Listens on port 8080 unless you or the Dockerfile say otherwise. Needs a default VPC in the region, which most AWS accounts have.
Kubernetes
Amazon EKS, or a cluster you connect
Run the app on a cluster you already have, or create one in the environment from a template. Pick Kubernetes on the Add page.
- A connected cluster needs its API endpoint and a service account token. Review the RBAC manifest with your DevOps team first.
- On a full-access, non-shared cluster, the free Microtica domain gives an address like <app>-<namespace>.microtica.rocks. Your own domain requires a paid plan.
- Launching on Kubernetes from the chat isn't available yet.
Serverless and static sites
AWS Lambda, CloudFront and S3
Start from a template for a serverless app or a single-page app served from a CDN.
- Templates set up the resources and the pipeline in your environment.
- Review the template's inputs before anything is created.
Infrastructure
Clusters, databases, networks
Add infrastructure from templates, or bring your own Terraform or CloudFormation components.
- Configure inputs for each environment and review before deploying.
- Connecting an account doesn't adopt existing resources or Terraform state.
Before you start
What to bring
- An app in a GitHub, GitLab or Bitbucket repository.
- A cloud account you can connect. On AWS, that means permission to create the connection's CloudFormation stack and IAM role.
- Your cloud provider bills the resources directly, separately from Microtica.
What you get
An app you can open, watch and change.
One page for the app
Visit it, read logs and events, follow deploys, change settings, or remove the app when you're done. The same page wherever it runs.
Deploys on every push
Each push to the branch builds and deploys, with the build and deploy logs one click away.
Releases when you need them
Ship several apps and components together, or promote staging to production, with one approval.
How releases work
Already running in production?
Plan the move before the deployment.
Start with a development environment. A production migration needs decisions about data, secrets, DNS, traffic and rollback.
Existing infrastructure
Map resource and state ownership
Connecting an account grants access. It doesn't adopt existing resources or Terraform state. Bring your architecture and deployment workflow to a technical demo.
Discuss your adoption pathPut your first app online.
Paste a repository, approve the plan and open your app.